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INTEGRATED CUSTOMER WEB STATION 
FOR WEB BASED CALL MANAGEMENT 

The present invention relates in general to 
telecommunications management, and more particularly to 
a web -based application for controlling routing of 
inbound toll free telephone calls through a 
telecommunications network for automatic call 
distribution to service centers or other operations. 

Major telecommunications service entities, 
e.g., MCI, AT&T, and Sprint, presently provide network 
planning and configuration products for monitoring 
multiple systems or call centers to their customers 
predominantly through a Windows -based graphical user 
interface resident on their computer workstations. For 
example, MCI's configuration management and AT&T's 
routing control service both provide 3270 emulation 
packages that offer the customer the ability to 
dynamically control the routing of their toll free 
services. Via the existing products, customers may 
specify routing conditions such as a sequence of 
alternate sites or tarunk groups where calls may be 
routed if a primary site is busy and already handling 
maximum calls allowed. Alternate routes are then 
searched in specified order looking for a site to take 
a call. Other products offer the ability to queue 
calls until a customer site is able to take a call. 
The length of the queue may be defined by a customer. 
Yet other products offer customers load balancing 
ability throughout a network, from a PC -based 
workstation at their sites. 

MCI currently provides its customers with a 
call manager workstation for providing various call 
routing management capabilities, including the ability 
to: provision toll free numbers, destinations, 
automatic call distributor (ACD) information, automatic 
number identification (AND lists, routing groups. 
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caller entered digits (CED) lists and user defined 
variables; display individual and agent group data; 
display termination cause values which are numeric 
codes that relate to a specific reason for routing a 
5 call, e.g., time out, normal routing, etc.; display 

system and application alarms; and display graphic or 
tabular ACD and regular peg -count data. 

With the existing products, however, service 
entity customers typically need to directly dial-up, 

10 e.g., via a modem, or, alternatively, via dedicated 

communication lines, e.g., ISDN, T-1, etc., to the 
entity's application and database servers, and initiate 
the network management application through the 
graphical user interface (GUI). Frequently, a dial-up 

15 modem and communications software interact with each 

other in many ways which are not always predictable to 
a custom application, requiring extensive 
troubleshooting and problem solving for an enterprise 
desiring to make a legacy system available to the 

20 customer, particularly where various telephone 

exchanges, dialing standards or signal standards are 
involved 

In addition, the aforementioned software is 
very hardware specific, and customers generally have a 

25 wide range of workstation vendors, which requires 

extensive inventory for distribution, and generally, 
intensive customer hand holding through initial setup 
and installation before reliable and secure sessions 
are possible. If the customer's hardware platform 

30 changes through an upgrade, many of these issues need 

renegotiation. Accordingly, it is highly desirable to 
integrate the existing call management client- server 
application in a Web-based platform which provides 
expedient, comprehensive and more secure data access 

35 and reporting services to customers from any Web 

-2- 
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browser on any computer workstation anywhere in the 
world. 

The present invention is one component of an 
integrated suite of customer network management and 
report applications using the Internet and a World Wide 
Web ("WWW" or "Web") Web browser paradigm. Introduced 
to the communications industry as the "networkMCI 
Interact," the integrated suite of Web-based 
applications provides an invaluable tool for enabling 
customers of a telecommunications enterprise to manage 
their telecommunication assets, quickly and securely, 
from anywhere in the world. In addition, the present 
invention has a capacity of functioning outside the 
integrated suite, i.e., as a standalone entity. 

The popularity of the public Internet 
provides a measure of platform independence for the 
customer, as the customer can run his/her own Internet 
Web browser and utilize his/her own platform connection 
to the Internet to enable service. This resolves many 
of the platfom hardware and connectivity issues in the 
customer's favor, and lets the customer choose their 
own platform and operating system. Web -based programs 
can minimize the need for training and support since 
they utilize existing client software, i.e. a Web 
browser, which the user has already installed and 
already knows how to use. Moreover, there is no longer 
a need to produce and distribute voluminous hard copies 
of documentation, including software user guides. 
Further, if the customer later changes that platform, 
then, as soon as the new platform is Internet enabled, 
service is restored to the customer. The connectivity 
and communications software burden is thus resolved in 
favor of standard and readily available hardware and 
the browser and dial-up software used to obtain the 
public Internet connection. 

-3- 
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An Internet delivered paradigm obviates many 
of the installation and configuration problems involved 
with initial setup and configuration of a customer 
workstation, since the custom application required to 
5 interface with the legacy system can be delivered via 

the public Internet and run within a standard Web 
browser, reducing application compatibility issues to 
browser compatibility issues. 

For the enterprise, the use of off-the-shelf 

10 Web browsers by the customer significantly simplifies 

the enterprise burden by limiting the client 
development side to screen layouts and data 
presentation tools that use a common interface enabled 
by the Web browser. Software development and support 

15 resources are thus available for the delivery of the 

enterprise legacy services and are not consumed by a 
need for customer support at the workstation level. 

The present invention is directed to a call 
routing management application, including a routing 

20 management workstation, referred to herein as a call 

manager webstation (CMWS) , which allows authorized 
customers to control toll free routing and monitor call 
center statuses. The terms call manager and call 
manager webstation will be used herein after and will 

25 refer to a system providing a call routing management 

capabilities. Via a web-based interface, customers may 
create and mamage routing rules which may be applied on 
an individual call basis, monitor one or more call 
center automatic call distributor (ACD) agent groups, 

30 and view alarms. The present invention also provides 

reporting, data extract, and bulk data loading 
capabilities via a web -based interface. 

The application features provided by the 
present invention include rules writing, testing and 

35 installation in which users are enabled to write rules 
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for routing of toll free calls. Rules may load balance 
based on the call center capacity and route based on a 
calling number, caller- entered digits, or call 
termination quotas. 
5 Furthermore, using the routing provisioning 

feature provided by the present invention, users may 
define tables and lists for use in routing rules. 
These tables include called numbers, destination 
labels, ACD agent groups, quota schemes, and ANI and/or 

10 CED translation tables. 

Moreover, with the graphic data displays and 
alarms features provided by the present invention, 
users may view near real-time displays of call center 
ACD statistics and peg counts based on routing rules. 

15 Peg counts generally refer to a number of times an 

action or condition occurs. With the reports and data 
extracts feature, users may run provisioning and 
statistical reports on provisioning and statistical 
data as well as view, print, or extract files for 

20 further analysis. 

The present invention also includes a user 
and business hierarchy maintenance feature for 
providing users with appropriate privileges with the 
ability to define business hierarchies, e.g., corporate 

25 or account group, to create and maintain user 

identifiers (ids) , and to assign data access 
privileges . 

In addition, the present invention supports 
multiple language displays, e.g., Canadian Frfench, cind 

30 . a branding feature which enables use of call routing 

management capabilities internationally, e.g., in a 
North America service offering. 

For providing the above functionalities, the 
present invention includes front- end client browser 

35 software including a web browser, HTML files including 
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files within which scripts written in JavaScript client 
scripting language are embedded, and Java application 
and applet codes, which are executed on the customer's 
desktop system, i.e., a workstation. The Java classes 
5 providing the user interface include user and business 

hierarchy, call by call application, graphic data 
display, alarm manager, and reporting/data extraction, 
each of which provides a corresponding application 
feature supported by the present invention. The above 

10 client browser software physically resides on a web 

server and is downloaded dynamically to the customer's 
system via their web browser and an Internet 
connection. 

The present invention also includes one or 

15 more web server (s) located in a demilitarized zone 

(DMZ) which is bounded by firewalls, for providing 
secure communications between the customer's 
workstation and the call manager webstation back-end 
systems. In addition, the web servers provide the 

20 state and session managements for the customer 

sessions. The web server classes implementing the web 
server functionalities include a session authentication 
manager for managing a customer session, and a 
transaction manager for receiving the web client 

25 transaction messages and communicating them to the 

back-end servers. 

The present invention also includes a proxy 
server for servicing the client transactions which are 
communicated over the Internet via the web servers by 

30 interfacing with the systems implementing the routing 

engine and network elements which provide and direct 
various call routing procedures. The back-end also 
includes a plurality of databases having near real-time 
network statistics data and alarms extracted from the 

35 routing engine cind/or network elements for providing 
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reporting functionality to the customers at the client 
workstation. The proxy server is generally responsible 
for receiving and reformatting the web client 
transactions into commands compatible with the routing 
5 engine which may be implemented in a host system, and 

also for the reverse process, i.e., receiving the 
routing engine transactions and reformatting them into 
web client message transactions for transmitting them 
to the web client via the web servers, thereby 

10 providing services to both the web client and the 

routing engine. It should be further noted that the 
routine engine need not be implemented in a large scale 
mainframe system. Rather, the routing engine may be 
supported by various processors having a wide range of 

15 processing capabilities. 

Further features and advantages of the 
present invention as well as the structure and 
operation of various embodiments of the present 
invention are described in detail below with reference 

20 to the accompanying drawings. In the drawings, like 

reference numbers indicate identical or functionally 
similar elements. 

Preferred embodiments of the present 
invention will now be described, by way of example 

25 only, with reference to the accompanying drawings in 

which like reference numbers indicate identical or 
functionally similar elements, and in which: 
Figure 1 illustrates the software 
architecture component comprising a three- tiered 

30 structure; 

Figure 2 is a diagrammatic overview of the 
software architecture of the networkMCI Interact 
system; 

Figure 3 is an illustrative example of a 
35 backplane architecture schematic viewed from a home 
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Figure 4 illustrates an example client GUI 
presented to the client/customer as a browser web page; 

Figure 5 illustrates an example of call 
5 manager webstation application physical architecture 

when one or more call manager web servers 632 bypass 
the CMIDS component of the present invention; 

Figure 6 illustrates a high level overview of 
the call manager system environment; 
10 Figure 7 illustrates call manager webstation 

component architecture of the present invention, 
showing interconnections among the components; 

Figure 8 illustrates one embodiment of the 
software architecture showing communications between 
15 the client 630 and the web server 632 and its 

components; 

Figure 9 illustrates the typical objects 
making up the client interface code, in one embodiment 
of the present invention; 
20 Figure 10 is an example of a CMIDS conceptual 

model 645 providing details of the CMIDS software 
components; 

Figure 11 illustrates a back-end process flow 
for the system of the present invention; 
25 Figure 12 illustrates an application- level 

process flow 800 for the system of the present 
invention; 

Figure 13 illustrates an example of a call 
manager webstation application screen including the 
30 toolbar and the rule writing palette; 

Figure 14 shows an example of a system status 

display; 

Figure 15 illustrates an example of a ACD 
collector administration function screen displayed for 
35 providing the user with the ability to view, create, 

-8- 
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delete and edit ACD collectors; 

Figure 16 illustrates a scenario diagram 
showing an example of branding process for presenting a 
warning dialog with a company brand; 
5 Figure 17 illustrates a scenario diagram for 

setting the locale for foreign language support; 

Figure 18 illustrates a CMResource class 
diagram used in internalization support; 

Figure 19 illustrates an example of a 
10 CMXXXString class diagram, used to support 

internalization by providing string mapping; 

Figure 20 illustrates an example of a 
CMXXXPhrases class diagram, used to support 
internalization by providing phrase translations; and 
15 Figure 21 illustrates an example of a class 

diagram including classes used in branding process. 

An overview of the Web -enabled integrated system 

20 The present invention is one component of an 

integrated suite of customer network management and 
report applications using a Web browser paradigm. 
Known as the networkMCI Interact system ("nMCI 
Interact") such an integrated suite of Web-based 

25 applications provides an invalueible tool for enabling 

customers to manage their telecommunication assets, 
quickly and securely, from anywhere in the world. 

The nMCI Interact system architecture is 
basically organized as a set of common components 

30 comprising the following: 

1) an object-oriented software architecture 
detailing the client and server based aspect of nMCI 
Interact; 

2) a network architecture defining the 

35 physical network needed to satisfy the security and 
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data volume requirements of the networkMCI System; 

3) a data architecture detailing the 
application, back-end or legacy data sources available 
for networkMCI Interact; and 

4) an infrastructure covering security, order 
entry, fulfillment, billing, self -monitoring, metrics 
and support. 

Each of these common component areas will be 
generally discussed hereinbelow. 

Figure 1 is a diagrammatic illustration of 
the software architecture component in which the 
present invention functions. A first or client tier 10 
of software services are resident on a customer 
workstation 10 and provides customer access to the 
enterprise system, having one or more downloadable 
application objects directed to front -end business 
logic, one or more backplane service objects for 
managing sessions, one or more presentation services 
objects for the presentation of customer options and 
customer requested data in a browser recognizable 
format and a customer supplied browser for presentation 
of customer options and data to the customer and for 
internet communications over the public Internet. 
Additional applications are directed to front -end 
services such as the presentation of data in the form 
of tcibles and charts, and data processing functions 
such as sorting and summarizing in a manner such that 
multiple programs are combined in a unified application 
suite. A second or middle tier 16, is provided 
having secure web servers and back-end services to 
provide applications that establish user sessions, 
govern user authentication and their entitlements, and 
communicate with adaptor programs to simplify the 
interchange of data across the network. 

A third or back-end tier 18 having 

-10- 
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applications directed to legacy back-end services 
including database storage and retrieval systems and 
one or more database servers for accessing system 
resources from one or more legacy hosts. 

Generally, the customer workstation includes 
client software capable of providing a platform- 
independent, browser-based, consistent user interface 
implementing objects programmed to provide a reusable 
and common GUI abstraction and problem -domain 
abstractions. More specifically, the client -tier 
software is created and distributed as a set of Java 
classes including the applet classes to provide an 
industrial strength, object-oriented environment over 
the Internet. Application- specif ic classes are 
designed to support the functionality and server 
interfaces for each application with the functionality 
delivered through the system being of two- types: 1) 
cross-product, for example, inbox and reporting 
functions, and 2) product specific, for example, toll 
free network management or call management functions. 
The system is capable of delivering to customers the 
functionality appropriate to their product mix. 

Figure 2 is a diagrammatic overview of the 
software architecture of the networkMCI Interact system 
including: the Customer Browser (a.k.a. the Client) 20; 
the Demilitarized Zone (DMZ) 17 comprising a Web 
Servers cluster 24; the MCI Intranet Dispatcher Searver 
26; and the MCI Intranet Application servers 30, and 
the data warehouses, legacy systems, etc. 40. 

The Customer Browser 20, is browser enabled 
and includes client applications responsible for 
presentation and front-end services. Its functions 
include providing a user interface to various MCI 
services cind supporting communications with MCI's 
Intranet web server cluster 24. As illustrated in 

-11- 
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Figure 3, the client tier software is responsible for 
presentation services to the customer and generally 
includes a web browser 14 and additional object- 
oriented programs residing in the client workstation 
platform 20. The client software is generally 
organized into a component architecture with each 
component generally comprising a specific application, 
providing an area of functionality. The applications 
generally are integrated using a "backplane'' services 
layer 12 which provides a set of services to the 
application objects that provide the front -end business 
logic. The backplane services layer 12 also manages the 
launching of the application objects. The networkMCI 
Interact common set of objects provide a set of 
services to each of the applications . The set of 
services include: 1) session management; 2) application 
launch; 3) inter -application communications; 4) window 
navigation among applications; 5) log management; and 
6) version management. 

The primary common object services include: 
graphical user Interface (GUI); communications; 
printing; user identity, authentication, and 
entitlements; data import and export; logging and 
statistics; error handling; and messaging services. 

Figure 3 is a diagrammatic example of a 
backplane architecture scheme illustrating the 
relationship among the common objects. In this 
example, the backplane services layer 12 is programmed 
as a Java applet which may be loaded and launched by 
the web browser 14. With reference to Figure 3, a 
typical user session starts with a web browser 14 
creating a backplane 12, after a successful log on. 
The backplane 12, inter alia, presents a user with an 
interface for networkMCI Interact application 
management. A typical user display provided by the 

-12- 
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backplane 12 may- show a number of applications the user 
is entitled to run, each application represented by 
buttons depicted in Figure 3 as buttons 58a, b,c 
selectable by the user. As illustrated in Figure 3, 
upon selection of an application, the backplane 12 
launches that specific application, for example. 
Service Inquiry 54a or Event Monitor 54b, by creating 
the application object. In processing its functions, 
each application in turn, may utilize common object 
services provided by the backplane 12. Figure 3 shows 
graphical user interface objects 56a, b created and used 
by a respective application 54a, b for its own 
presentation purposes. 

Figure 4 illustrates an example client GUI 
presented to the client/customer as a browser web page 
250 providing, for example, a suite 252 of network 
management reporting applications including: MCI 
Traffic Monitor 252c; Call Manager 252f ; a Network 
Manager 252e and Online Invoice 252i* Access to 
network functionality is also provided through Report 
Requester 252b, which provides a variety of detailed 
reports for the client/customer and a Message Center 
252a for providing enhancements and functionality to 
traditional e-mail communications. 

As shown in Figures 3 and 4, the browser 
resident GUI of the present invention implements a 
single object, COBackPlane which keeps track of all 
those client applications implemented as deriving from 
the COApp or COApplet classes, as will be described 
below. The COBackPlane abject includes the 
capabilities to start, stop, and provide references to 
any one of these client applications. Additionally, a 
client application may be invoked from the home page 
(Figure 4) by a direct URL launch. In this case, a new 
Web page having an applet providing the functionalities 

-13- 
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of the desired application may be retrieved and 
presented to the user from the home page (Figure 4) , 
The call manager of the present invention includes such 
an implementation for initiating the call manager 
client application. 

The backplane 12 and the client applications 
use a browser 14 such as the Microsoft Explorer 
versions 4.0.1 or higher for an access and distribution 
mechanism. Although the backplane is initiated with a 
browser 14, the client applications are generally 
isolated from the browser in that they typically 
present their user interfaces in a separate frame, 
rather than sitting inside a Web page. 

The backplane architecture is implemented 
with several primary classes. These classes include 
COBackPlane, COApp, COAppImpl, COParm, and COAppFrame 
classes. COBackPlane 12 is an application backplane 
which launches the applications 54a, 54b, typically 
implemented as COApp. COBackPlane 12 is generally 
implemented as a Java applet and is launched by the Web 
browser 14. This backplane applet is responsible for 
launching and closing the COApps. 

When the backplane is implemented as an 
applet, it overrides standard Applet methods initO, 
startO, stopO and runO. In the initO method, the 
backplcine applet obtains a COUser user context object. 
The COUser object holds information such as user 
profile, applications and their entitlements. The 
user's configuration and application entitlements 
provided in the COUser context are used to construct 
the application toolbar and Inbox applications. When 
an application toolbar icon is clicked, a particular 
COApp is launched by launchAppO method. The launched 
application then may use the backplane for inter- 
application communications, including retrieving Inbox 

-14- 



SUBSTITUTE SHEET (RULE 26) 



wo 99/16218 




PCTAJS98/20157 



data, 

The COBackPlane 12 includes methods for 
providing a reference to a particular COApp, for 
interoperation. For example, the COBackPlane class 
provides a getAppO method which returns references to 
application objects by name. Once retrieved in this 
manner, the application object's public interface may 
be used directly. 

As shown in Figure 2, the aforesaid objects 
will communicate the data by establishing a secure TCP 
messaging session with one of the DMZ networkMCI 
Interact Web searvers 24 via an Internet secure 
commxinlcations path 22 established, preferably, with a 
secure sockets SSL version of HTTPS. The DMZ 
networkMCI Interact Web servers 24 function to decrypt 
the client message, preferably via the SSL 
implementation, and unwrap the session key and verify 
the users session. After establishing that the request 
has come from a valid user and mapping the request to 
its associated session, the DMZ Web servers 24 re- 
encrypt the request using symmetric encryption and 
forward it over a second socket connection 23 to the 
dispatch server 26 inside the enterprise Intranet. 

The DMZ is a special secure network area set 
aside exclusively for potentially hostile customer 
access. All DMZ equipment is physically isolated and 
firewalled from the enterprise Intranet. Similarly, 
the DMZ equipment is firewalled and obscured from 
hostile attacks from the public Internet, except for 
limited Web browser access to the Web servers which are 
located in the DMZ. The customer's Web browser 
connects to a Web server in the DMZ which in turn acts 
as a proxy to extract select information from midrange 
servers located in the enterprise Intranet. A customer 
never directly connects to servers in the enterprise, 

-15- 
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thus ensuring internal enterprise system security and 
integrity. 

The DMZ acts as a doiable firewall for 
enterprise Intranet from the public Internet because 
5 the Web servers located in the DMZ never store or 

compute actual customer sensitive data. The Web 
servers only put the data into a form suitable for 
display by the customer's Web browser. Since the DMZ 
Web servers do not store customer data, there is a much 

10 smaller chance of any customer information being 

jeopardized in case of a security breach. 

A networkMCI Interact session is designated 
by a logon, successful authentication, followed by use 
of server resources, and logoff. However, the world- 

15 wide web communications protocol uses HTTP, a stateless 

protocol, each HTTP request and reply is a separate 
TCP/IP connection, completely independent of all 
previous or future connections between the same server 
and client. The nMCI Interact system is implemented 

20 with a secure version of HTTP such as S-HTTP or HTTPS, 

and preferably utilizes the SSL implementation of 
HTTPS. The preferred embodiment uses SSL which 
provides a cipher spec message which provides server 
authentication during a session. The preferred 

25 embodiment further associates a given HTTPS request 

with a logical session which is initiated and tracked 
by a "cookie jar server*' 28 to generate a "cookie" 
which is a unique server -generated key that is sent to 
the client along with each reply to a HTTPS request. 

30 The client holds the cookie and returns it to the 

server as part of each subsequent HTTPS request. As 
desired, either the Web servers 24, the cookie jar 
server 28 or the Dispatch Server 26, may maintain the 
"cookie jar' to map these keys to the associated 

35 session. A separate cookie jar server 28, as 
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illustrated in Figure 2 has been found desirable to 
minimize the load on the dispatch server 26. This form 
of session management also functions as an 
authentication of each HTTPS request, adding an 
5 additional level of security to the overall process. 

As illustrated in Figure 2, after one of the 
DMZ Web servers 24 decrypts and verifies the user 
session, it forwards the message through a firewall 25b 
over a TCP/IP connection 23 to the dispatch server 26 

10 on a new TCP socket while the original socket 22 from 

the browser is blocking, waiting for a response. The 
dispatch server 26 unwraps an outer protocol layer of 
the message from the DMZ services cluster 24, and re- 
encrypts the message with symmetric encryption and 

15 forwards the message to an appropriate application 

proxy via a third TCP/IP socket 27. While waiting for 
the proxy response all three of the sockets 22, 23, 27 
block on a receive. Specifically, once the message is 
decrypted, the wrappers are examined to reveal the user 

20 and the target middle-tier (Intranet application) 

service for the request. A first -level validation is 
performed, making sure that the user is entitled to 
communicate with the desired service. The user's 
entitlements in this regard are fetched by the dispatch 

25 server 26 from the StarOE server 49 at logon time and 

cached . 

If the requestor is authorized to communicate 
with the target service, the message is forwarded to 
the desired service's proxy. Each application proxy is 

30 an application specific daemon which resides on a 

specific Intranet server, shown in Figure 2 as a suite 
of mid-range servers 30. Each Intranet application 
server of suite 30 is generally responsible for 
providing a specific back-end service requested by the 

35 client, and, is additionally capable of requesting 
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services from other Intranet application servers by 
communicating to the specific proxy associated with 
that other application server. Thus, an application 
server not only can offer its browser a client to 
server interface through the proxy, but also may offer 
all its services from its proxy to other application 
servers. In effect, the application servers requesting 
services are acting as clients to the application 
servers providing the services. Such mechanism 
increases the security of the overall system as well as 
reducing the n\iraber of interfaces. 

The network architecture of Figure 2 may also 
include a variety of application specific proxies 
having associated Intranet application servers 
including: a StarOE proxy for the StarOE application 
server 39 for handling authentication order 
entry/billing; an Inbox proxy for the Inbox application 
server 31, which functions as a container for completed 
reports, call detail data and marketing news messages; 
a Report Manager proxy capable of communicating with a 
system- specific Report Manager server 32 for 
generation, management and receipt notification of 
customized reports; a Report Scheduler proxy for 
performing the scheduling and requests of the 
customized reports. The customized reports include, 
for example: call usage analysis information provided 
from the StarODS server 33; network traffic 
analysis /monitor information provided from the Traffic 
view server 34 ; virtual data network alarms cuid 
performance reports provided by Broadband server 35; 
trouble tickets for switching, transmission and traffic 
faults provided by Service Inquiry server 36; and toll 
free routing information provided by Toll Free Network 
Manager server 37. 

As partially shown in Figure 2, it is 
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understood that each Intranet server of suite 30 
communicates with one or several consolidated network 
databases which include each customer's network 
management information and data. As shown in Figure 2, 
5 other legacy platforms 40 (b), 40(c) and 40(d), 610 may 

communicate individually with the Intranet servers for 
servicing specific transactions initiated at the client 
browser. The illustrated legacy platforms 40 (b) - (d) , 
610 are illustrative only and it is understood other 

10 legacy platforms may be interpreted into the network 

architecture illustrated in Figure 2 through an 
intermediate midrange server 30. 

Each of the individual proxies may be 
maintained on the dispatch server 26, the related 

15 application server, or a separate proxy server situated 

between the dispatch server 26 and the midrange server 
30, The relevant proxy waits for requests from an 
application client running on the customer's 
workstation 10 and then services the request, either by 

20 handling them internally or forwarding them to its 

associated Intranet application server 30. The proxies 
additionally receive appropriate responses back from an 
Intranet application server 30. Any data returned from 
the Intranet application server 30 is translated back 

25 to client format, and returned over the internet to the 

client workstation 10 via the Dispatch Server 26 and at 
one of the web servers in the DMZ Services cluster 24 
and a secure sockets connection. When the resultant 
response header and trailing application specific data 

30 are sent back to the client browser from the proxy, the 

messages will cascade all the way back to the browser 
14 in real time, limited only by the transmission 
latency speed of the network. 

The networkMCI Interact middle tier software 

35 includes a communications component offering three (3) 
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types of data transport mechanisms: 1) Synchronous; 2) 
Asynchronous; and 3) Bulk transfer. Synchronous 
transaction is used for situations in which data will 
be returned by the application server 40 quickly. 
5 Thus, a single TCP connection will be made and kept 

open until the full response has been retrieved. 
Asynchronous transaction is supported 
generally for situations in which there may be a long 
delay in application server 40 response. Specifically, 

10 a proxy will accept a request from a customer or client 

10 via an SSL connection and then respond to the client 
10 with a unique identifier and close the socket 
connection. The client 10 may then poll repeatedly on 
a periodic basis until the response is ready. Each 

15 poll will occur on a new socket connection to the 

proxy, and the proxy will either respond with the 
resultant data or, respond that the request is still in 
progress. This will reduce the number of resource 
consuming TCP connections open at any time and permit a 

20 user to close their browser or disconnect a modem and 

return later to check for results. 

Bulk transfer is generally intended for large 
data transfers and are unlimited in size. Bulk 
transfer permits cancellation during a trcinsfer and 

25 allows the programmer to code resumption of a transfer 

at a later point in time. 

As described herein, the data architecture 
component of networkMCI Interact reporting system is 
focused on the presentation of real time (un- priced) 

30 call detail data, such as provided by MCI's TrafficView 

Server 34, and priced call detail data and reports, 
such as provided by MCI's StarODS Server 33 in a 
variety of user selected formats. 

All reporting is provided through a Report 

35 Requestor GUI application interface which supports 
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spreadsheet presentation, a variety of graph and chart 
type presentations, or both simultaneously. For 
example, the spreadsheet presentation allows for 
sorting by any arbitrary set of coluinns. The report 
5 viewer may also be launched from the inbox when a 

report is selected. 

A common database may be maintained to hold 
the common configuration data which may be used by the 
GUI applications and by the mid- range servers. Such 

10 common data includes but are not limited to: customer 

security profiles, billing hierarchies for each 
customer, general reference data (states, NPA's, 
Country codes), and customer specific pick lists: e.g., 
ANI's, calling cards, etc.. An MCI Internet StarOE 

15 server manages the data base for the common 

configuration of data. 

Report management related data is also 
generated which includes 1) report profiles defining 
the types of reports that are available, fields for the 

20 reports, default sort options and customizations 

allowed; and 2) report requests defining customer 
specific report requests including report type, report 
name, scheduling criteria, and subtotal fields. This 
type of data is typically resident in a Report Manager 

25 server database and managed by the report manager* 

The Infrastructure component of the nMCI 
Reporting system includes mechanisms for providing 
secure communications regardless of the data content 
being communicated. The nMCI Interact system security 

30 infrastructure includes: 1) authentication, including 

the use of passwords and digital certificates; 2) 
public key encryption, such as employed by a secure 
sockets layer (SSL) encryption protocol; 3) firewalls, 
such as described above with reference to the network 

35 architecture component; and 4) non- repudiation 
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techniques to guarantee that a message originating from 
a source is the actual identified sender. One 
technique employed to combat repudiation includes use 
of an audit trail with electronically signed one-way 
message digests included with each transaction* 

Another component of the nMCI Interact 
infrastructure includes order entry, which is supported 
by the Order Entry CStarOE") server. The general 
categories of features to be ordered include: 1) Priced 
Reporting; 2) Real-time reporting; 3) Priced Call 
Detail; 4) Real Time Call Detail; 5) Broadband SNMP 
Alarming; 6) Broadband Reports; 7) Inbound RTM; 8) 
Outbound RTM; 9) Toll Free Network Manager; and 10) 
Call Manager. The order entry functionality is 
extended to additionally support 11) Event Monitor; 12) 
Service Inquiry; 13) Outbound Network Manager; and, 14) 
Online Invoicing. 

The self -monitoring infrastructure component 
for nMCI Interact is the employment of mid- range 
servers that support SNMP alerts at the hardware level. 
In addition, all software processes must generate 
alerts based on process health, connectivity, and 
availability of resources (e.g., disk usage, CPU 
utilization, database availability) . 

The Metrics infrastructure component for nMCI 
Interact is the employment of mechanisms to monitor 
throughput and volumes at the Web servers, dispatcher 
server, application proxies and mid- range servers. 
Metrics monitoring helps in the determination of 
hardware cind network growth. 

To provide the areas of functionality 
described above, the client tier 10 is organized into a 
component architecture, with each component providing 
one of the areas of functionality. The client -tier 
software is organized into a ^'component' architecture 
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supporting such applications as inbox fetch and inbox 
management, report viewer and report requestor, TFm, 
Event Monitor, Broadband, Real-Time Monitor, and system 
administration applications. Further functionality 
integrated into the software architecture includes 
applications such as Outbound Network Manager, Call 
Manager, Service Inquiry and Online invoicing. 

Call manager web station application 

The call manager system or the present 
invention provides sophisticated mechanisms, e.g., 
intelligent call routing, for call center customers to 
control delivery of toll free calls from the 
telecommunications enterprise network to call centers, 
including call centers having multiple ACDs* 
Particularly, using the system of the present 
invention, the customers have the ability to define 
routing rules which, on an individual call basis, 
determine the best place to route incoming toll free 
calls. A high level overview of the call manager 
system environment is illustrated in Figure 6, The 
call manager system generally includes: a service 
control point (SCP) 610, for providing call manager 
routing features, known as "call by call" routing; an 
intelligent routing host (IR host) 612; and client 
workstations, i,e., call manager webstation client 630. 
The SCP 610 is a routing engine which essentially 
maintains call routing rules and uses those rules to 
determine where to route the calls. The SCP 610 shown 
and described hereinafter, is used as an example of a 
system implementing the routing engine. It should be 
noted that the routing engine implementation is not 
limited to and need not reside in a mainframe system. 
Rather, the routing engine may also be supported by 
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various types of -processors having a wide range of 
processing capability. 

A typical call processing flow for a call 
received from a caller 622 includes routing requests 
5 and responses from the enterprise switches 624 through 

data access points (DAPs) 616 and remote data gateways 
(RDGs) 618 into and out of the SCP 610* The DAP 616 
executes a routing plan by translating a toll free 
niimber passed by the switch 624 into a network number, 

10 and maps it to an address. The RDG 618 provides a 

standard gateway allowing communication between the SCP 
610 and the enterprise's backbone network. The 
translated network number is then communicated to the 
SCP 610 via the RDG 618. 

15 Data collection and storage of ACD-based 

statistics from customer call centers euid network 
statistics are supported by DAP traffic statistics 
(DTS) 614, and the IR host 612. The DTS collects 
network routing statistics from the DAP 616 and passes 

20 them to the IR host 612. The IR host 612 stores 

routing statistics from DTS 614 and the ACD 620. The 
ACD 620 data statistics are collected for each ACD 620 
and normalized by the IR host 612, and provided to the 
routing engine, e.g., SCP 610. When the SCP 610 

25 receives a routing request, the SCP 610 typically 

determines the best location to route a call by 
modeling each call center using periodic Automatic Call 
Distributor (ACD) 620 data statistics to keep the model 
in line with what is actually going on at each 

30 location. 

Upon completion of call processing according 
to a customer routing plan, the DAP 616 passes routing 
instructions to the switch 624 for setting up the call 
to a customer's ACD 620. The ACD 620 balances the load 
35 of calls based upon customer defined rules such as the 
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"busy-ness" of a call center. Calls may be distributed 
evenly using a "round robin" technique, or directed in 
which calls are routed based on a percentage allotted 
to each destination identifier. Voice comrnunications 
are carried from the switch 624 to the ACD 620 which 
terminates the call at the appropriate trunk or 
destination identifier. 

The routing capabilities supported by SCP 610 
include a termination selection based upon one or more 
of the following: initial list of eligible 
destinations, destinations eliminated from 
consideration based upon tested conditions, 
artificially biased evaluation criteria, percent 
allocation, and manipulation of user- defined peg- 
counter variables. The SCP 610 also supports the 
routing and blocking of incoming calls using event - 
level data based on one or more of the following 
characteristics: day of the week, day of year, 
preference of destination choices, time of day, 
membership of the automatic number identification (AND 
or caller entered digits (CED) in a defined list of 
values, load balancing and/or availability at specific 
destinations, user -defined quota schemes, user -defined 
peg -counters, preference of destination choices, and 
artificial bias of load balancing algorithms. 

The Call Manager Integrated Data Server {s) 
(CMIDS) 640 are included to provide a front -end 
functionality to the routing engine, e.g., SCP 610, and 
off-load various workstation- related processing from 
the routing engine. In addition, the CMIDS 640 may 
directly access data stored on the IR host or on other 
data servers. Further details of the CMIDS 640 will be 
described with references to Figures 7 and 10. 

The call manager system of the present 
invention further includes one or more web servers 632 
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for providing browser-based customer connections from 
the World Wide Web (WWW or Web) • The call manager web 
server 632 passes the customer connections through to 
the SCP 610 via the CMIDS 640, and thus delivers the 
5 - call manager functionality to the call manager 

webstation client 630 via a standard web browser and 
the Internet. 

The call manager webstation 630 may be any 
hardware/software platform connected to the public 

10 Internet and running a supported web browser, e.g., 

Internet Explorer V4.01. The call manager webstation 
620 is typically owned and maintained by the customer. 
The call manager webstation 630 includes a web -based 
graphical user interface (GUI) application which 

15 enables the customers to define their call 

tenninations, and provision routing rules and 
associated tabular data to control routing by the SCP 
610. The GUI application also presents alarms and near 
real time graphical displays of peg counts and ACD- 

20 based statistics. The application also provides 

reports and data extracts of historical data, including 
call detail records (CDRs) , ACD-based statistic, and 
peg counts. In addition, user- id administration 
functions including business hierarchy structures and 

25 function profiles may be performed via the call manager 

webstation' s web-based GUI application. 



Call Manager Webstation a rchitecture 

30 Figure 7 illustrates the call manager 

webstation component architecture of the present 
invention, showing interconnections among the 
components. In a preferred embodiment, the call 
manager webstation system includes three components of 

35- the call manager platform: client desktop systems, or 
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workstations, hereinafter referred to also as the 
client webstations 630 for delivering call routing 
management functions through a standard web browser; a 
web server 632 for supporting secure access for 
5 internet or extranet/ intranet -based clients to call 

manager back-end and thus to the routing engine, e.g., 
SCP systems; and call manager integrated data server 
(CMIDS) 640, forming an integral part of the back-end 
call manager application and supporting access to the 

10 routing engine, e,g., SCP systems. As shown in Figure 

7, the client desktop systems 630 with Internet 
connectivity have standard browsers executing Java 
applets, hereinafter referred to also as a client GUI 
application, downloaded from the web server 632, The 

15 web server 632 which is located in the demilitarized 

zone (DMZ) of the network MCI Interact, include Java 
class files, but no storage of customer data to insure 
data security. Preferably, more than one web server 
may be provided for redundancy and fail -over 

20 capability. The DMZ is generally bounded by two 

firewalls: an Internet firewall 660 and an enterprise 
intranet firewall 662. The call manager integrated 
data server (CMIDS) generally handles the business and 
data logic associated with the call manager 

25 functionality. Each of the above components will now 

be described in detail with reference to additional 
figures. 

As described above, the client webstation 630 
provides a web -based graphical user interface (GUI) 

30 offering data management and data presentation features 

for the call manager system. The web-based front-end 
GUI is typically written using the Java programming 
language to insure platform independence. The client 
webstation 630 typically includes a web browser with 

35 Java applets for the interface for providing access to 
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the call manager -webstation application from a standard 
web browser, e.g., Internet Explorer V4.01. In 
addition, the networkMCI Interact common objects are 
used for implementing many functions needed for 
client/server communications protocols. The Java 
applets generally reside on the web servers 632 and are 
dynamically downloaded to the client browsers (client 
webstations) 63 0 when the Uniform Resource Locator 
(URL) for the call manager webstation client GUI 
application is accessed. 

The call manager webstation client GUI 
application of the system of the present invention is 
invoked by clicking an icon labeled "call manager" 
(Figure 4 at 252f) from the networkMCI Interact home 
page (Figure 4) . The customer is then presented with a 
toolbar for launching each of the call manager 
webstation application features (Figure 13 at 880) . 
Moreover, on-line help is offered via hyper- text markup 
language (HTML) documents residing on the web servers 
632. Furthermore, the displays, including the on-line 
help may be presented to the customers in a language 
chosen by the customer or in a language of the 
geographic locale, e.g., English, or French. 

Each call manager webstation application 
feature may be accessed through an icon button on a 
tool bar (Figure 13 at 880) . Moreover, each feature is 
brought up in a separate window frame, giving a 
consistent look and feel throughout the web 
enviroiunent. The main features offered include: user 
setup and administration, i.e., security functions 
(Figure 13 at 882); business hierarchy setup; call by 
call application for rules writing and provisioning 
(Figure 13 at 874, 884); graphic data display (Figure 
13 at 878); alarm manager (Figure 13 at 872); reporting 
and data extracts (Figure 13 at 876) ; and host 
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Utilities {Figure- 13 at 877) . A detailed description 
for each of feature will be provided with reference to 
Figure 12 below. 

For providing the above features, the client 
browser includes class objects shown in Figure 9, 
Figure 9 illustrates the typical objects making up the 
client interface code in one embodiment of the present 
invention. The user interface classes 634 represent 
the main GUI objects for performing call manager 
specific functionality. Each of the classes, i.e., 
user and business hierarchy setup, call by call 
application, graphic data display, alarm manager, 
reporting extracts, and authentication/ entitlements, 
performs the corresponding client- side functionality 
associated with the call manager features provided. 
The web server classes 638 provide the communication 
pass through to the back-end server. The communication 
classes (not shown) are employed between the client 
browser 630 and the web server 632 for requesting 
transactions and/or data sets from the web server 632. 

In one embodiment of the invention, the 
communications from the client 630 and back-end (Figure 
7 at 640) via the web server 632 are conducted using 
the common gateway interface (CGI) . Requests from the 
client are typically first targeted at a CGI program, 
which then relays the request to the appropriate proxy 
process. Results are returned from back-end processes 
to the requesting client in the same manner. Each 
transaction or data request may be executed as a 
separate process, to allow processing to continue from 
other applications within the call manager webstation 
system. 

In a preferred embodiment, a Netscape Server 
Application Program Interface (NSAPI) module may be 
used as an alternative to the CGI layer, the NSAPI 
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module replacing the CGI -protocol communications layer 
between the client 530 and the web server 632. The web 
server 632 may be configured to pick up the NSAPI 
module and load on start up. Java client code 634 may 
5 be configured to refer to the NSAPI module. For 

example, the Java client may invoke a method to 
communicate directly with the NSAPI module that 
performs the same function as the CGI program. Using 
the NSAPI module enhances performance and messaging 

10 throughput. When the server 632 recognizes requests 

for the NSAPI module, it invokes a particular function 
in the module which performs essentially the same 
function as the CGI program. For example, a middle 
tier transaction handler, typically a message manager 

15 (msgmgr) and residing with the web servers 632, may be 

modified to use the NSAPI instead of the HTTP CGI. The 
advantage of NSAPI over CGI is that a new process need 
not be created whenever a request comes in from the web 
client 630. 

20 In general, and as described above, the web 

server 632 provides a communication pass -through 
between the web client GUI application 630 and the 
back-end call manager integrated data server (CMIDS) 
640 which may communicate with the routing engine, 

25 e.g., SCP. Figure 8 illustrates one embodiment of the 

software architecture showing communications between 
the client 630 and the web server 632 and its 
components. The web server 632 provides web-based call 
routing management applications to web clients having a 

30 web browser on their client workstations 630. The web 

server 632 includes an HTTP service manager 652 and a 
message manager 656. The HTTP service manager 652 
generally ha.ndles requests from multiple clients 630 to 
download web pages and Java applets for display within 

35 a browser. Web pages include hypertext markup language 
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(HTML) files and -Java applets 654 that are downloaded 
to the clients 630 and are executed within a browser by 
the Java applets. The HTTP service manager 652 also 
handles message transactions via the POST method 
5 defined by the hyper- text transfer protocol (HTTP) 

protocol. The HTTP service manager may be standard 
off-the-shelf World Wide Web server software, e.g., 
Netscape Enterprise Server, 

The message manager 656 is typically a CGI 

10 program that is executed as a spawned process within 

the HTTP service manager 652 when a message transaction 
is received from the client via the POST method sent to 
the HTTPS port (443) 650, The HTTP service manager 652 
spawns a process to run an instance of the message 

15 manager 656 each time it receives a message transaction 

from the client. Alternately, the message manager 656 
may be implemented as a function in the NSAPI module as 
described above. The HTTP service manager 652 then 
invokes the message function in the NSAPI module. Both 

20 input and output streams are created by the message 

manager 656 to receive message data from the client 630 
and to reply back to the client 630. The message 
manager 656 is generally responsible for the following: 
1) accepting new user log in by allocating a new 

25 session key for a newly created session; 2) attaching a 

dispatcher and proxy header to the web client's message 
and forwarding the message to the proxy server 670; and 
receiving a routing engine, e.g., SCP, response message 
from the proxy server 670 and re -wrapping this message 

30 with dispatcher and proxy header and sending this 

formatted message to the web client 630. Message 
transactions are sent to the proxy server 670 over a 
new connection by opening a new TCP socket to the proxy 
server 670 while the original socket from the browser 

35 is blocking, waiting for a response from the web server 
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632, 

Typically, communications to and from the 
client 63 0 take place over hyper- text transfer protocol 
secure (HTTPS) , which uses hyper- text transfer protocol 
5 (HTTP) over a secure socket layer (SSL) encrypted 

channel. Applications may include web pages in the 
form of hyper- text markup language (HTML) files and 
Java applets 654 that are stored on the web server 632 . 
The HTTP service manager 652 downloads the HTML files 

10 and Java applets 654 to the client 630 upon request via 

the HTTPS port 650, typically configured to port n\imber 
443. Each transaction from a client 630 is sent to the 
web server 632 in the foann of a logical message that 
has been encrypted. The web server 632 decrypts the 

15 message and wraps the message with the user's 

information, including environment variables and a 
server -generated session identifier (id) . The message 
is then encrypted and forwarded to the CMID 640, or 
alternately, as will be described below, to the proxy 

20 server component of the CMID 640. 

As described above, the message transactions 
created by the client 630 may be transmitted over HTTPS 
using the POST method defined within the HTTP protocol. 
Using the POST method, a specified CGI program and more 

25 specifically, an invoked message manager runs as a 

thread in the HTTP service manager 652. Message data 
is passed to the message manager 656 by opening an 
input stream and an output stream within the thread. 
As described previously, the HTTP service manager 652 

30 spawns a message manager process 656 for each message 

transaction sent to web server 632. Each message 
transaction is a single request from the client 630 
that is answered by a single reply from the web server 
632. 

35 The web server 632 also includes a session 
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manager 658 and a session table 660 for providing 
session management functions including the 
authentication of various web requests. A session is 
defined as the amount of time between which a client 
5 630 logs onto the web server 632 and when the client 

logs off. During a session, a client 630 may submit 
many message transactions to the web server 632. State 
data for each session is stored in the session table 
660. Session entries are deleted from the session 

10 table 660 when a user logs off or when a session is 

aged. Each message transaction received by the web 
server 632 is associated with an active session. If a 
session no longer exists for a particular transaction, 
the message transaction is returned to the client 63 0 

15 as rejected. The application then may prompt the user 

to login again. 

Generally, the session table 660 is a table 
that has state information on all current client 
sessions that are active on the web server 632. When a 

20 client logs onto the web server 632 and is 

authenticated, the client is provided a "session id* 
which is a unique server -generated key. The client 
holds this and returns it to the server as part of 
subsequent message transaction. The session table 660 

25 maintains a "session key table" which maps these keys 

to the associated session. The session table also 
includes a time stamp for each client session. A 
client session's time stamp is updated each time a 
message transaction containing the session id for the 

30 session is received. A session is aged if no message 

transactions belonging to the session are seen after a 
given amount of time. If so, the session, with its 
entry deleted from the session table 660, is logged off 
from the SCP 610. 

35 The session manager 658 is generally 
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responsible for monitoring all current client sessions. 
The session manager 658 typically monitors the sessions 
by accessing the session table 660 and checking the 
current time stamp values for each current session, if 
the time stamp value shows that a session has aged, the 
session entry for the aged session is cleared from the 
session table 660. Clearing the session entry forces 
any further message transactions associated with the 
session identifier to be rejected, requiring the user 
to restart the session. 

For communications to and from the web client 
630 and the back-end, the middle-tier web seirver 362 
supports three types of transport mechanism which are 
provided by the networkMCI Interact platform: 
synchronous, asynchronous, and bulk transfer. The 
Synchronous transaction type typically has a single TCP 
connection which is kept open until a full message 
reply has been retrieved. The Asynchronous transaction 
type is typically used for handling message 
transactions requiring a long delay in the back-end 
searver response. A server process handling the message 
transaction responds back to the web client 630 
immediately with a unique transaction identifier and 
then closes the connection. The web client 630 may 
then poll the web server 632 using the transaction 
identifier to determine when the original message 
transaction has completed. The bulk transfer type of 
transport mechanism is typically used for large data 
transfers which may be virtually unlimited in size. 

In the embodiment shown in Figure 8, the web 
server 632 includes a proxy server 670 and a database 
672, e.g., Informix database. In this embodiment, the 
web server 632 includes the capability to communicate 
directly to the routing engine, e.g., SCP, bypassing 
the CMIDS 640, by having the proxy server reside 
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physically in the web server. Figure 5 illustrates an 
example of call manager webstation application physical 
architecture when one or more call manager web servers 
632 bypass the CMIDS component of the present 
5 invention. As shown, the call manager web servers 632 

directly communicate the messages, i.e., translated 
client requests, to the SCP 610. In addition, in this 
embodiment, it is the SCP 610 which receives ACD 
statistics, alarms and other information from the IR 

10 host 612, and communicates the information to the web 

servers 632. As described previously, the SCP 610 
serves as the routing engine through which customers 
provision routing rules and associated tables or list, 
view alarms, route peg counts, etc. It houses the 

15 applications used by customers to manipulate the 

features of their automated call distributor (ACD) 
Figure 5 also shows the call manager web client 630 as 
being authenticated via the networkMCI Interact 
platform and its StarOE authentication and entitlement 

20 system 631. Briefly, customers who have subscribed to 

the call manager through the networkMCI Interact suite 
may access the application via the networkMCI Interact 
home page. The customer is typically prompted for a 
name and password entry. The networkMCI Interact 

25 platform validates the password and authenticates with 

the StarOE system 631, verifying that a customer's 
profile allows access to the call manager webstation 
application- Upon valid authentication, the call 
manager webstation application session may begin with 

30 the client webstation communicating with the call 

manager web servers 632 for providing the various 
functionalities . 

In another embodiment, as will be described 
below with reference to the CMIDS 640 illustrated in 

35 Figure 10, the data processing components for business 
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and data logic, i.e., the proxy server and the database 
resides with the CMIDS 640, thereby reducing the 
functions of the web server 632 to an application 
server providing primarily state and session 
5 management. Porting the proxy server 670 over to the 

CMIDS 640 may be easily performed. The transaction 
handler in the middle tier, i.e., the message manager 
656 still passes messages between the Web client 630 
and the CMIDS 640. The only change needed is that the 

10 transaction handler connects to the proxy residing on 

the CMIDS 640, as opposed to the proxy 670 on the web 
server 632. 

The proxy server 670 generally processes 
message transactions from the client 63 0 and is 

15 multithreaded to handle multiple message transactions 

simultaneously. The proxy server 670 is designed to 
process one type of message transaction or a set of 
message transactions. In this embodiment, routing of 
the messages to and from the proxy is handled by the 

20 message manager 656. The proxy server 670 also 

interacts with a database 672, e.g., Informix, to pass 
back information to be displayed by the client 630. 
The proxy server opens a connection to the SCP 610 to 
retrieve information about routing plans or report 

25 statistics by sending the SCP *man machine language* 

protocol (MML) commands. Upon retrieval, the proxy 
server 670 formats a response message which is sent 
back to the client webstation 630 so that it is 
displayed on the current web page. As the message 

30 reply is sent back to the client 630, each thread 

created by the proxy server 670 is completed. It 
should be noted that the proxy server 670 need not 
reside in the web servers 632. Instead, as will be 
described with reference to Figure 10, the proxy server 

35 670 may reside in the CMIDS 640, the back-end server 
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component . 

The database 672 generally maintains 
information needed to translate the messages to and 
from the SCP 610, A message translation program 
5 written in 4GL accesses the database 672 when a message 

transaction is received • The program translates the 
message and sends the message to the SCP 610 for 
processing. After the message has been processed, the 
program translates the response and sends it back to 

10 the message manager 656. The proxy server 670 

typically invokes an instance of the translation 
program for each message transaction it receives and 
processes. As noted above with reference to the proxy 
server, the database 672 may also alternately reside in 

15 the CMIDS with the proxy server. 

In a first preferred embodiment, the present 
invention includes a data server, i.e., the CMIDS. In 
this embodiment, much of the functions of the proxy 
server are performed within the data server. More 

20 specifically, the proxy server 670 and the database 672 

may be ported over to the CMIDS 640. The web server 
672 communicates to the proxy in the CMIDS 640 which 
then communicates with the routing engine, e.g., SCP 
(Figures 6, 7 at 610). The call manager integrated 

25 data server (CMIDS) 640 generally services web requests 

for the webstation application and serves as a front - 
end for the routing engine, e.g., SCP (Figures 6, 7 at 
610). Referring back to Figure 7, the CMIDS 640, in 
addition, provides data storage and management for data 

30 resident on the SCP 610, the IR host 612, and/or other 

servers. The CMIDS 640 also provides pass through 
connectivity for rules writing and other provisioning 
from the client webstation 630 to the routing engine, 
e.g., SCP 610. The CMIDS includes databases 642a-c and 

35 provides an interface to the call manager SCP 610 for 
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rules writing and list management. The CMIDS databases 
642a-c are extracted or replicated from the routing 
engine, e.g., SCP 610, and/or the IR host 612. In an 
example shown, the SCP 610 services are requested and 
5 satisfied through a protocol known as *man machine 

language* (MML) commands. The CMIDS 640 utilizes MML 
as well as other interface mechanisms supported by the 
SCP 610. The call manager integrated data server 
(CMIDS) 640 physically resides on hardware located 

10 behind the intranet firewall 662 as shown. 

The proxy server 670 and the database 672 
which were described with reference to the web server 
632, may reside in the CMIDS 640. In addition, the 
CMIDS 640 may also include a session manager 658 and 

15 associated session table 660 for managing the client 

sessions. As described above, the proxy server 670 
generally handles webstation client 630 requests passed 
from the web servers 632 by accepting message 
transactions from the webstation client 630 via the web 

20 servers 632, maintains logging information, sends the 

request to a session manager 658, and receives data 
from the back-end and forwards data to the web servers 
632. 

The session manager 658, residing in the 
25 CMIDS 640, receives data from the proxy server 670. 

The session manager 658 updates the sessions table 660, 
validates that the user has proper privilege to perform 
the task. The user validation function may be 
performed for the webstation client 630 also, in 
30 addition to a validation conducted by the networkMCI 

Interact StarOE authentication and entitlement system 
during the session log on. 

The CMIDS 640 also may include a routing 
engine formatter, a CMIDS transaction manager, and a 
35 routing engine port manager. The session manager 658 
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typically passes -a transaction request received from 
the web server 632 to either the routing engine host 
formatter, or the CMID transaction manager. The routing 
engine host formatter module services transactions 
5 requiring SCP services to fulfill the request. The 

transactions originating from a webstation client 630, 
are translated to a correct MML format and sent to the 
routing engine port manager component. 

The CMIDS transaction manager module services 

10 transactions that do not require the routing engine, 

e.g., SCP 610, i^e., the types of client request which 
may be serviced locally on CMIDS, including: obtaining 
NEMS alarm information, obtaining GDD information, and 
processing of user security. When the local processing 

15 is complete, results are sent back to the proxy server 

670 component. 

The routing engine port manager component of 
the CMIDS manages pools of session with one or more 
routing engines, e.g., SCPs 610. The routing engine 

20 port manager logs onto each session in a pool using a 

"generic" user id. Using a "generic* user id enables 
each session to access an individual user's data 
without having to log each user onto the SCP 610. MML 
commands for a particular user are sent to a SCP using 

25 any available session in the pool of "generic" session. 

After an MML command is sent and a response is 
received, the session is returned to the session pool 
and freed for use by the succeeding transactions. A 
session pool is defined as a set of sessions connected 

30 to one particular SCP 610. Therefore, the routing 

engine port manager component of CMIDS 640 supports 
multiple session pools for communicating with multiple 
SCPs 610. 

The routing engine port manager also 
35 maintains the state of each session in each pool. The 
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port manager generates a keep -alive -message whenever a 
session is idle to keep the SCP 610 connection from 
being dropped. If a session in a pool has failed, the 
routing engine port manager will try to reestablish the 
5 session and add it back into the pool when 

establishment is completed. The routing engine port 
manager determines the communication channel to use to 
access the SCP 610 and keeps a nxamber of connections 
open to the SCP 610. Each message is sent to the SCP 
10 610 and the channel blocked until a response is 

received. 

Figure 10 illustrates an example of a CMIDS 
conceptual model 645 providing details of the CMIDS 
software components. The CMIDS software architecture 
15 includes proxy 670, system administration, and inbox 

648 components offering functions analogous to the 
networkMCI Interact equivalents, but applicable to the 
call manager webs tat ion (CMWS) application 
specifically. 

20 The proxy 670 software component was 

described above with reference to Figure 8. As shown, 
the proxy 670 may reside in the CMIDS, and provide the 
functionalities described above. The user account 
interface software component 643 generally maintains 

25 sessions with the SCPs and provides the functions of 

the routing engine port manager described above. The 
report handler process generally maintains databases 
642a-c and provides reporting facilities. The CMIDS 
back-end interface 712 supports a number of interface 

30 mechanisms including MML and command line access to the 

SCP, common alarm and logging services, and data 
retrieval from the IR host. 

Figure 11 illustrates a back-end process flow 
for the system of the present invention. A customer 

35 622 typically dials a toll-free number. As an 
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illustrative example, this toll-free number may be 
provided by a company having operators taking telephone 
orders. In addition, the company provides three trunk 
lines or destination identifiers going into its ACD. 
5 The company services a call centered media-based sales 

application, e.g., home shopping network, through this 
ACD which includes a toll-free number for customers to 
call. To handle calls to the home shopping network 
client, the company sets up an ACD path group called 
10 'HSN." This ACD path group includes the three trunk 

lines as member destinations and reports agent and call 
statistics from the total number of agents servicing 
home shopping network, regardless of the particular 
trunk lines. 

15 Accordingly, as shown at step 752, when the 

customer 622 dials the toll-free number, the call goes 
to the network through the switch. At step 754, the 
call is passed from the switch to the DAP for 
translation. The DAP translates the toll-free number 

20 to a network number and maps it to an address readable 

by the RDG. NetCap 758 generally houses routing plans, 
destination labels, toll-free numbers, logical 
terminations, DAP -based details and trigger plans 
required for the call manager webstation system. Most 

25 of this data may be provisioned in NetCap 758 via the 

Toll Free Network Manager (TFNM) application service. 
The TFNM is described in detail in the co-pending U.S. 

Patent Application Serial No. , contents and 

disclosure of which are incorporated by reference as if 

30 fully set forth herein. Seeing the trigger point and 

other DAP -based data provisioned from NetCap 758, the 
DAP passes the call to the RDG at step 756. At step 
760, call statistics are saved in DAP traffic 
statistics (DTS) for use in case of time-out or other 

35 failures. They are also stored within the IR host. At 
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Step 762, the RDGv with its ability to communicate with 
the SCP, passes the network nximber and associated 
address to the call -by- call routing application on the 
SCP. Based on instructions in the rule set defined by 
5 the call manager webstation system customer, the call 

by call application selects the HSN ACD path group at 
step 764. At step 768, call by call application then 
selects the individual destination identifier within 
the ACD path based on the specified distribution method 

10 which may be either even/ "round robin" or 

directed/percentage distribution. At step 770, the 
call is routed back through the RDG to the DAP. Then 
at step 772, the DAP routes the call to the ACD via the 
specified destination id or trunk. Specifically, 

15 referring back to the above illustrated example, calls 

received on Thursdays between 5:00 and 7:00 GMT may be 
set to be routed to Orlando, and accordingly the 
destination id is Orlando Central. The call by call 
routing application returns destination id "Orlando 

20 Central" to the network, which routes the call to the 

ACD via the Orlando Central destination id or trunk. 

r^n Ti^AT^^qAir client QUI application implem^tation 

As described previously, the call manager 
client software uses the networkMCI Interact common 
objects (CO) . Generally, the CO includes a library of 
objects that minimizes the replication of code, and 
provides a framework in which a family of Internet 
applications may be managed and created. This 
framework includes communications, I/O services to 
local resources, user authentication, 

internationalization, common look and feel, application 
management, and a model view controller (MVC) 
framework. The call manager client classes typically 
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derive from the GO classes. 

The application backplane architecture 
supports the plugging in of applications into one Java 
applet, which allows for one application's classes to 
5 use another's services. Accordingly, a COBackPlane 

class is derived from the Java applet class, and the 
networkMCI Interact backplane logic is implemented as 
an instance of the COBackPlane class. A class COApp 
acts like a Java applet, but does not derive from the 

10 Java Applet class. The COApp s may be started and 

stopped from the class COBackPlane. 

Each COApp frame is derived from a 
COAppframe, which has one or more COViews, a part of 
the standard MVC paradigm. The MVC paradigm allows for 

15 easy handling of multiple views of a data model. The 

model is a wrapper for an application data object. A 
controller is a lightweight event handling class, which 
translates GUI events into commands for the 
application. The view is one particular GUI 

20 representation of the model. In a MVC typical 

operation, views register with a model, allowing the 
updating of multiple views when the model changes. 
Each view has a controller, which handles the GUI 
events, and translates them into command descriptions. 

25 The model stores command descriptions, which for 

example, enables the undo and redo functionality in the 
application. 

The call manager client application (CMApp) 
is preferably derived from the COApp class and may be 

30 launched by a backplane object that is typically 

derived from the COBackPlane class, including the 
networkMCI Interact backplane. 

In a first embodiment of the present 
invention, the call manager client application is 

35 launched in a separate browser window from the one 
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within which the -networkMCI Interact backplane is 
running. For example, after validating that a 
customer's profile allows access to the call manager 
application, and after a customer clicks the call 
5 manager icon on the networkMCI Interact home page 

(Figure 4) , the networkMCI Interact backplane creates a 
separate browser window and populates the call manager 
webstation URL. The call manager webstation web server 
then dovmloads the call manager client application for 

10 execution within the new browser window. 

In a second embodiment, the call manager 
webstation application may be launched as a standalone, 
i.e., outside the networkMCI Interact home page. For 
example, a customer may retrieve the web page the call 

15 manager webstation application directly from the 

client's web browser by pointing to the call manager 
webstation URL. The call manager webstation web server 
then downloads the call manager client application for 
execution, in a similar manner as the first embodiment 

20 described above. 

The call manager client application 
downloaded from the server includes a CMBackPlane class 
which is applet derived from the COBackPlane class and 
which inherits the attributes of the COBackPlane class. 

25 The CMBackPlane is launched with the call manager 

webstation web page and provides backplane 
functionalities within the context of the call manager 
webstation application. The call manager client 
application also includes a aFeature class from which 

30 the CMFeature is derived. The CMFeature typically is 

invoked by the CMApp and provides an application 
specific fvmctionality within the call manager 
application such as reporting, alarm management (NEM) , 
graphical data display (GDD) , and call by call 

35 application. 
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The browser typically starts the call routing 
management applet which launches a CMApp by calling its 
init method. The CMApp sets and displays a main 
toolbar which may be implemented using a view of a 
model in a MVC paradigm described above. When a user 
presses a button on the main toolbar to launch a 
feature; e.g., NEMS, Rules, etc., the CMAppView derived 
from the theMainToolbar class creates/activates the 
selected feature and initializes it. When the 
CMFeature is instantiated or started, it invokes a 
method to create a frame, the CMFeatureFrame, in which 
to run the selected feature. 

Call manager vebstation application features 

As described above, the call manager 
webstation application allows authorized customers to 
manage their ACD data networks via a web -based 
interface. Specifically, customers are enabled to 
provision hierarchies for their business; control all 
routing of their toll-free traffic; create, modify or 
delete agent pools; manipulate capacity tables; and 
define quota schemes, value lists and schedule tables. 
Figure 12 illustrates an application- level process flow 
800 for the system of the present invention. A 
customer at a client webstation 63 0 having Internet 
connectivity and a web browser, for example, the 
Internet Explorer® 4.01, accesses the call manager 
webstation application by pointing the browser to the 
networkMCI Interact URL as shown at step 802. At step 
804, the customer is then presented with a networkMCI 
Interact log on screen where the customer types in a 
name and password pair. At step 806, the log on applet 
associated with the log on page typically checks the 
entered name and password. At step 808, if the log on 
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name and password is determined to be invalid, the 
customer is prompted to reenter the log on transaction 
at step 804. If the log on transaction is valid, the 
customer is presented with the networkMCI Interact home 
5 page (Figure 4) downloaded from the web server. With 

downloading and presenting of the home page, the web 
browser at the webstation 630, deploys a backplane 
applet via which the call mcinager client GUI 
application may be invoked. 

10 As described in reference to Figures 3 and 4, 

the application backplane is a Java® applet invoked 
inside the networkMCI Interact' s home page and is the 
conduit through which all other client applications may 
be deployed, including the call manager webstation GUI 

15 client application. At step 810, the backplane 

requests a list of authorized applications from the 
StarOE authentication and entitlement system for the 
networkMCI Interact platform. At step 812, a select 
list of applications which may include the call manager 

20 webstation application of the present invention, is 

enabled on the home page according to the customer 
specific entitlements, as received from the StarOE. 
The call manager webstation application may then 
typically be accessed from the home page (Figure 4) 

25 with an icon labeled "call manager" 252f (Figure 4) as 

shown at step 814. Accordingly, a call manager 
webstation session begins when a customer clicks on the 
call manager icon, triggering the backplane to launch 
the call manager webstation client GUI application. 

30 At step 816, the customer is then presented 

with a call manager webstation application log on 
dialog, on which the customer enters the call manager 
webstation log on name and password. In addition, the 
customer may be presented with a change password 

35 dialog. This dialog implements a password expiration 

-46- 



SUBSTITUTE SHEET (RULE 26) 



wo 99/16218 



PCT/US98/20157 



design feature supported by the present invention. 
Generally, for security reasons, a password is valid 
for a predetermined period of time. After that period, 
the customer must change to a new password. 

In addition, multiple engines may be handled 
through the web client front -end and translation 
processing at the back-end. The front -end client 
application sends a command to retrieve a list of SCP 
names. The host information is stored at the back-end 
with the Informix database and, typically an SQL 
routine retrieves the available SCP. The proxy 
residing at the back-end returns a list of the 
available SCP to the front -end web GUI client 
application. The proxy generally maintains a "routing 
engine" list having SCP neimes and their IP addresses. 
Maintaining the list of routing engine names on the 
proxy allows for easy modification of routing engine 
names and IP addresses with no impact to the client 
code. 

When the front -end web GUI client application 
receives the list, a list of routing engine names may 
be displayed in a drop- down list for the customer to 
select, or the customer may be prompted for the SCP 
desired. The selected routing engine name is sent 
along with a log in transaction having user 
name/password to the back-end, when the customer clicks 
a ''log in" button from the log in dialog. The 
"establish- session* command is then sent to the back- 
end where the proxy may open a connection to that 
routing engine. The proxy maps the SCP name to the 
appropriate IP address and forwards the user log in 
request to the routing engine. The SCP id selected at 
log in is populated in the toolbar at the client 
webs tat ion. 

Referring back to Figure 12, at step 820, the 

-47- 



SUBSTITUTE SHEET (RULE 26) 



wo 99/16218 




PCT/US98/20157 



entered log in name is validated typically by the call 
manager webs tat ion web server or the proxy as described 
with reference to their functionalities above. At step 
822, if the log on is valid, the call manager 
5 webstation applet is downloaded to the customer 

webstation 630, and at step 824, the customer is 
presented with the screen 870 shown in Figure 13 
through which the customer may perform the call manager 
features of the present invention provided. These 

10 features include: manipulating user and business 

hierarchy by querying, creating, or editing user id 
records as shown at steps 826 and 828; managing routing 
schemes via the call by call application as shown at 
steps 830 and 832a-k; invoking alarm manager at step 

15 834 and 836 to view problems occurring across the call 

manager components, such as loss of connectivity, 
failure of ACD data collection, system failures, and 
application abnormalities; reporting and data extracts 
at steps 83 8, 840 for printing, displaying and managing 

20 ACD statistics, alarm history, database usage, peg 

counter, and system performance; graphic data display 
at steps 842, 844 for viewing histograms and charts of 
ACD and peg -count statistics; managing host utilities 
at step 831; requesting service at step 833; and 

25 retrieving on-line help at step 835, 

More specifically, by selecting the option at 
step 826, to manage a user and business hierarchy, via, 
e.g., the security button 882 (Figure 13) from the 
toolbar 880 (Figure 13) , a customer may search for a 

30 user id and, with appropriate privileges, create or 

edit a user id for a business level below their own. 
Through this option the customer may also access 
reporting visibility to all data items belonging to the 
customer and any business level below their own. In 

35 addition, the customer may assign a read, read/write, 
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or no access privileges to each function in the user id 
profile. More over, the customers may administer and 
modify limits on the number of entities that a business 
unit may own in the provisioning database. 
5 By selecting the call by call application at 

step 830, for example, by clicking on an icon labeled 
"Provisioning" (Figure 13 at 874) on the call manager 
web station tool bar displayed on the screen 870 in 
Figure 13, the customer may perform business hierarchy 

10 provisioning as shown at step 832a. The customer may 

select the option at step 832b and perform load- 
balancing by determining the degree of "busy-ness" by 
tracking the average call handling time, the number of 
agents, and the number of calls routed to each 

15 destination. At steps 832c and 832e, the customer is 

enabled to provision capacity tables for providing a 
default staffing allocation for use by the load 
balancing algorithm. With the call by call option as 
shown at step 832dr the customer may also provision 

20 basic destination ids representing a single call 

termination on the network which may be a single 
telephone instrument or a line termination into a PBX. 
Destination ids with ACD feeds, which may represent a 
single call termination into an ACD, may also be 

25 provisioned. Provisioning of ACD path groups 

representing a set of destination ids that terminate on 
the same physical ACD emd share the same statistical 
data feed is also enabled. Provisioning of Destination 
Groups representing a set of logically related 

30 destination ids and/or ACD path groups is possible via 

the call by call option. Destination Groups are a 
convenience mechcuiism for writing rules that refer to 
multiple destinations without having to list each 
destination separately. In addition, the customer may 

35 provision distribution methods, e.g., an even 
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distribution method, which is a round- robin selection 
of destination ids, or a directed distribution method, 
in which the calls are routed to destination ids based 
on a percentage allotted to each destination id, 
5 At step 832f , customers may specify and 

maintain call routing quotas for destinations. At step 
832g, the customer is enabled to provision called 
nvimbers. For example, the customer creates a rule set 
associated with the called nximber. The rule set 

10 typically determines the location of the caller and 

selects the appropriate destination nxamber for the 
nearest warehouse. At step 832h, the customer may 
provision value lists which are sets of related numeric 
values. They are typically used in rule sets to test 

15 the attributes of an incoming call to determine a 

characteristic of the call or caller. An attribute of 
the call (such as the ANI) is tested against a value 
list. If the value of the call attribute matches an 
entry in the value list, then other rules are executed 

20 based on this logical condition. This feature is 

highly useful for non- English -speaking callers. At 
step 832i, the customer may provision translation 
tables. The translation tables include a highly 
flexible mechanism for performing a table lookup and 

25 returning a value that corresponds with the search 

argument. At steps 832 j and 832k, the customers may 
maintain user variables such as setting up names for 
peg counters and rule variables and routing 
instructions . 

30 By selecting the alarm manager option at step 

834, for example, by clicking on an icon labeled "NEMS" 
(Figure 13 at 872) on the call manager web station tool 
bar displayed on the screen 870 in Figure 13, the 
customer may display various alarms for problems 

35 occurring across the call manager components. These 
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components were described above. Typically, alarming 
is performed through the BMC patrol software agents 
with monitoring provided by the system operational 
support (SOS) organization, which monitors other 
5 components of the call manager platform. Patrol's 

"logwatch.conf ig" allows setting up a file name and a 
selection string. Patrol agents typically monitor the 
file and pass alarms matching the selection string to 
the web clients. For logging application level alarms, 

10 a UNIX syslog facility is used. A set of "send- alarm 

functions" interfaced between the application processes 
and syslog daemon is added to a common utility library. 
Through the send- alarm function the call manager 
application processes send the alarm messages to the 

15 same log file with different levels of severity. The 

alarms with high level of severity is generally 
monitored by system operational support (SOS) 
organization through BMC patrol software. Each alarm 
message typically includes a process name, an alarm 

20 number, and a severity level. A typical alarm message 

looks like: *Apr 8 17:23:31 cmjwstest Process Name 
[Process PID] : [LOG_Alert Number] can't set up a 
connection to XXX Nexus at Line 65 File proxy." The 
alert number then may be used to determine possible 

25 solutions. 

Referring back to Figure 12, selecting the 
reporting and data extracts option at step 838, for 
example, by clicking on an icon labeled 'Reporting' 
(Figure 13 at 876) on the call manager web station tool 

30 bar displayed on the screen 870 in Figure 13, enables 

the customer to obtain reports of ACD statistics, alarm 
history, database usage, CDR extracts. Peg counters, 
and system perf ormcince. Each of these reports may be 
generated on-line or by a print function within the 

35 application. The ACD statistics are monitored in live, 
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near -real -time by- the SCP application. A load- 
balancing algorithm uses ACD statistics to determine 
the "busy-ness" of a destination. When an ACD Path 
Group is selected as the least busy location by the 
5 load -balancing algorithm, one of the individual 

destination ids within that ACD path group is picked to 
carry the call. The reports of alarm history permit 
the customer to view the status of alarms and events on 
the various hosts. An alarm or event may be an 

10 informational message sent autonomously from a host. 

Database usage reports generally provide information on 
users, typically by user id, accessing a workstation, 
SCP, or call by call application. The CDR extracts 
generally provide a database record of call detail 

15 record information about a called number translation 

query and its outcome of the routing translation 
process. Peg counters generally represent a series of 
accumulators that are available to the user for 
counting actions or situations encountered in a rule 

20 set. System performance reports allow the customer at 

a workstation (webstation) to monitor capacity of the 
host and application components to foresee and prevent 
possible outages. 

Additional ACD statistical data which may be 

25 viewed and monitored via the tool bar (Figure 13 at 

880) include: (1) the niimber of calls abandoned during 
a reporting interval; (2) the number of calls answered 
during a reporting interval; (3) the number of calls 
completed during a reporting interval; (4) the n\Hnber 

30 of agents currently available to take calls; (5) the 

number of agents currently handling active calls; (6) 
the n\imber of agents currently performing follow-up or 
after-call activities; (7) the number of agents logged 
in to the ACD but who are not available to handle calls 

35 due to an airxiliary work; (8) the total number of 
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agents available including those handling active calls 
and/or performing follow-up work related to a call; (9) 
the total number of agents currently logged in to the 
ACD including those agents in auxiliary work state; 
5 (10) the number of calls currently in queue waiting for 

an available agent; (11) the percentage of calls 
abandoned during a reporting interval; (12) the number 
of seconds the oldest call in queue has been waiting; 
(13) the average time to handle a call including talk 

10 time and after-call work time; (14) the average time 

the calls wait in queue for the available agents; (15) 
the average time in queue for the calls which were 
abandoned; and (16) a total demand time denoting a 
ratio of a number of calls to a niimber of agents 

15 working on calls. 

Selecting the graphic data display option at 
step 842, for example, by clicking on an icon labeled 
''GDD" (Figure 13 at 878) on the call manager web 
station tool bar displayed on the screen 870 in Figure 

20 13, enables the customer to obtain and view histogram, 

chart, cind line graph displays of ACD-based statistics 
and routing peg counts, which may be refreshed as 
frequently as once per minute. 

Selecting the service contact option at step 833, 

25 for example, by clicking on an icon labeled "Cust 

Service* (Figure 13 at 879) enables the customer to 
contact and/or request services relating the 
telecommunications routing management. Similarly, 
selecting the service on-line help option at step 833, 

30 e.g., by clicking on the icon labeled 'Help" (Figure 13 

at 875), enables the customer to retrieve the on-line 
help. 

35 

-53- 



SUBSTITUTE SHEET (RULE 26) 



wo 99/16218 




PCT/US98/20157 



Rules writing, testing, debugging application features 

The rules feature (Figure 13 at 884) allows 
users to write rules for routing of toll free calls. 
Rules may load balance based on call center capacity 
and route based on automatic number identification 
(AND, caller entered digits (CED) , or quotas. Via 
this feature, users may also test, install, uninstall, 
and swap rules as shown at Figure 13. The bottom half 
of screen 870 in Figure 13 displays a typical rules 
writing/editing template. The users may build rules on 
the rules construction area 882 by including statements 
selected from the constructs list box and the 
statements list box 884, The users may also select 
various options 886 available for the selected 
construct or statement for building the rule. 

For enabling a rule writer to test a rule set, the 
rules feature provides a rules debugger/ tester 
functionality which runs a rule set against a set of 
test data, i.e., call context, simulating call 
scenarios in which to test a rule set logic. This 
optional facility allows rule writers to check if their 
rule set exhibits the expected behavior, for example, 
before installing the rule set on the network. 
Moreover, because this test feature is purely optional, 
a rule writer need not run the rule testing 
functionality before the rule is installed. 

When a customer, e.g., a rule writer, selects 
the debugger/ tester feature option, a rules testing 
dialog appears. Via this dialog, a user may define a 
call context parameters for simulating call scenarios 
in which to test a rule set logic. The basic call 
context includes called -number, ANI, CED, carrier, date 
and time of the call. Optionally, the user may also 
modify the different parameters of destinations and 
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quotas that may affect the load balancing. 

In addition, an option to allow the database 
to be updated during the simulation is also provided. 
During the testing process, the customer may step 
through the simulation one line at a time or choose a 
''Run" command to nin through the entire call all at 
once. Furthermore, during the simulation, the customer 
may select from various view tabs to view, including, a 
log view, a destination status view, a destination 
details view, a CDR view and a user variable view. 

For executing the testing process, the 
debugger/ tester uses the MML interface to the routing 
engine, i.e., the debugger/ tester formulates the user 
actions to one or more MML commands and sends the 
translated command to the SCP. The SCP typically 
stores the state of testing (including the different 
views of the log) , and manages the test execution. 

System s tatus display 

Typically, a system status display 960 shown 
in Figure 14, is opened by selecting "Host Utilities" 
from the security (Figure 13 at 877) button on the main 
toolbar. The dialog is non-modal. The top half of the 
dialog 962 includes general information about the 
system. The bottom half includes a combination box 964 
that allows the user to select between the different 
options described above, i.e., application status, ACD 
gateway status, partner links status, signaling network 
links status, and webstation session links status. 
Selecting an option displays a list including 
infonnation relevant to that option. As shown at 964, 
selection of the application status displays 
information which include application names 966, 
instance numbers 968, desired states 970, actual states 
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972, release numbers 974 and TPS 976. Similarly, 
selecting the ACD gateway status option displays 
information including gateway names, gateway states, 
gateway link states, collector link states, and 
5 dates/ times of last change. Selecting the partner 

links status option displays routing engine names, 
states, link states, sync states information. Likewise 
the signaling network links status option displays 
information which includes linkset names, link names, 

10 states, dates/ times of last change, and adjacent point 

codes. Selecting the WebStation session links status 
option displays information such as workstation 
instance numbers, locations, states, user ids, and 
dates/ times of last change. 

15 When the dialog first opens, an "ACT -DSP" 

message is sent to let the routing engine know that the 
user is ready to start receiving system status 
messages. An example of an MML message sent includes: 

20 server. StreamPair : SCP client: [ACT-DSP: : rOOOlO; ] 

server. StreamPair : SCP server: [ SCP 98/01/08 12:26:06 
M 00010 COMPLD;] 

When the message is received at the routing engine, the 
25 routine engine sends system status messages on a 

regular interval. The length of the interval may vary 
anywhere from every second to every minute. An example 
of routing engine status messages include: 

30 Server. StreamPair : SCP server: [ SCP 98/01/08 12:26:07A 

1 KEPT STAT sysstat 

3. 2. 11, A, 63, 213179, 58, 0,0, 0,0, 0,0, 299, 0,0, 1,0,0;] 
server. StreamPair : SCP server: [ SCP 98/01/08 12:26:07 
A 2 REPT STAT link 
35 SNET,RDG,RDG,InActive, 12/20/97, 17\:32\: 41, 
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SNET, RDG, RDG, InActive, 12/20/97 , 17\ : 32\ : 41 , 
SNET, RDG, RDG, Active, 01/08/98 , i2\ : 26\ : 02 , 
SNET, RDG, RDG, Active, 01/08/98 , 12\ : 25\ : 58 , 
SNET, RDG, RDG, InActive, 12/20/97 , 17\ : 32\ :41, 
5 SNET, RDG, RDG, InActive, 12/20/97 , 17\ : 32\ : 41, 

ACD, N/A,N/A, Active, 12/29/97 , 14\ : 25\ : 30 . IRHOST 
LSE,LSE,LSE -None, Active, 12/31/97 , 07\ : 34\ : 05, 
WKS, ,100\ , Active, 01/08/98, 11\:29\: 14, msinith 
WKS, ,101\ , Active, 01/08/98, ll\:52\:52,egriffin 
10 WKS,,102\ ,Active, 01/07/98, 14\:00\:23,njones 

WKS, , 103\ .Active, 01/08/98, 12\:09\: 31, sysadmin 
WKS, ,104\ , Active, 01/08/98, 12\:21\:32,raniku 
WKS, , 105*, Active, 01/08/98, 12\:25\: 53, Imurray;] 
server. StreamPair : SCP server: [ SCP 98/01/08 12:26:07 
15 A3 REPT STAT appl 

cxc , 0 , InService, InService ,3.2.11,0;] 

server. StreamPair : SCP server: [ SCP 98/01/08 12:26:07 
A 4 REPT STAT net mci_nom. A, - , PrimaryOOS ; ] 

In order to limit the amount of message 
traffic having to be sent to and from the client, data 
for these messages may be included into one message, 
"get- sys- Stat." Preferably, the SCP sends the get-sys- 
stat message every 5 seconds. Each get-sys-stat is 
typically preceded by an "ru- alive' message that forces 
the back-end to read the socket for the latest data. 
When the user chooses to close the dialog, the messages 
are stopped by sending a canc-dsp message. An example 
of a canc-dsp message is shown below. 

server. StreamPair : SCP client: [CANC-DSP: :: 00012;] 
server . StreamPair : SCP server: [ SCP 98/01/08 12:26:10 
M 00012 COMPLD;] 
35 
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The system status display messages are 
automatically sent from the SCP, once the messages are 
turned on. The back-end typically stores this type of 
message received from the SCP until the client queries 
for it. System status messages are generally stored in 
the following tables: 

stat_appl for KEPT STAT appl messages, 
stat__link for KEPT STAT link messages, 
stat_net for REPT STAT net messages, and 
stat„sysstat for REPT STAT sysstat messages. 

A unique set of data is stored for each user 
currently performing a system status display. 
Subsequent messages received from the SCP typically 
overwrite previous data. For example, if the backend 
receives two (2) REPT STAT net messages before the 
client queries for the first, the second overwrites the 
first. 

The host administration func tions 
A user may select to perform host 
administrations by selecting the appropriate icon from 
the main tool bar (Figure 13 at 877) . Then a pull -down 
menu is presented with options including: backup, ACD 
gateway administration, ACD collector administration, 
FMS gateway administration, and FMS collector 
administration . 

For backing up server database to either a 
tape or a disk, a user may select a "Backup" option 
from the administration button menu and invoke the 
backup functionality. The client GUI application sends 
a "RTRV-BK- STATUS' message to check the status of the 
back-end. If a return message is not "INPROGESS", a 
dialog box is opened for enabling the user to select 
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the backup mediiim, i.e., tape, or disk. When the user 
selects a tape or disk option and clicks the start 
button, a "START -BACKUP" message is sent to the back- 
end. Subsequently, "RTRV-BK- STATUS" messages are sent 
5 every 5 seconds to retrieve the current status of the 

backup processing. The timer continues to increment 
every second, and the progress bar is continuously 
updated until the return message *DONE" is received. 
On the other hand, if the 'START -BACKUP" message fails, 

10 an appropriate error dialog id displayed. 

In addition, once the backup progress starts, 
the close button's text changes to "Cancel." Clicking 
the close or the cancel button while a backup is in 
progress prompts the user to cancel that backup. If 

15 the user selects yes, a CANC-BACKUP message is sent. 

Clicking the close button when a backup is not in 
progress closes the dialog box. 

The ACD gateway administration provides the 
users the ability to view, create, delete and edit ACD 

20 gateways. The ACD collector administration function 

provides the user with the ability to view, create, 
delete and edit ACD collectors. When this option is 
selected, a dialog 980 shown in Figure 15 opens with a 
list of retrieved gateway types. Typically the client 

25 GUI application sends two messages to retrieve 

information needed to populate the dialog box 980. A 
"rtrv-acd-type" is used to fill the gateway type combo 
box 982. A 'rtrv-acd- status" is sent to retrieve 
information 984 on the selected gateway type. Clicking 

30 a row in the list 984 enables the delete button 986. 

Typing characters into the site collector name 988 
enables the Add button 990. 

The FMS gateway administration and the FMS 
collector administration options provide the ability to 

35 view, create, delete and edit FMS gateways and 
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collectors, respectively. The FMS administration 
dialogs share the same dialog box with the above 
described ACD gateway and collector administration 
functionalities. The same messages, i.e., the 'rtrv- 
acd-type", and the ''rtrv-acd-status* , are sent to the 
back-end but with different parameter types, e.g., 
*FSM* or "ACD." 

COlttPanV hT-andinq 

The present invention supports a branding 
functionality which allows users to open the call 
manager webstation application in a company specific 
context. Figure 21 illustrates an example of a class 
diagram including classes used in branding process. 
The CMBackPlane class 924 is derived from the 
COBackPlane class 1066 which is an applet 1064, 
inheriting all the applet attributes and methods. The 
main URL for the call manager webstation application 
uses JavaScript, a client -side scripting language, to 
render the html. The JavaScript, typically, directs 
the browser to retrieve a company brand. The browser 
then opens the call manager webstation application web 
page with the company brand specified in the query 
portion of the URL. Figure 16 illustrates a scenario 
diagram showing an example of a branding process for 
presenting a warning dialog with a company brand. 
Typically, the call manager applet 924 retrieves a 
company brand name by invoking a getParameter 1014 
method (an applet method) , and sets the brand name in 
the CMGlobals class 1010 by invoking a setBrand method 
1022. When a WamingDialog 1012 is initialized 1018, 
it retrieves the brand name by invoking a getBrand 
method 1016 from the CMGlobals 1010 and displays the 
brand name on the dialog box upon a popup 1020. 
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T.aT^qiiaq e SUDT>Ort 

The present invention includes an 
internationalization feature, supporting local 
languages for text displays. This optional feature 
5 allows a user to open the call manager application in a 

language as set by the user. Subsequent texts and 
phrases are rendered in the language chosen. 
Typically, the call manager webstation application is 
opened with a default language as set by the operating 

10 system. The user is also given an option to select a 

language other than the default. A call manager applet 
typically determines the locale set for the operating 
system and launches the appropriate language version by 
including the locale as a parameter. For example, the 

15 parameter with a name "locale" may have one of the 

following values: "en_US' for English US, "en^CA" for 
English* Canada, and *fr_CA'' for French Canada. The 
applet uses this value to set the locale for the system 
string and phrase resources. Figure 17 illustrates a 

20 scenario diagram for setting the locale. The call 

manager applet 924 determines the locale setting by 
invoking a getParameter method 1006, and sets the 
locale by invoking a setLocale method 1008 and using 
the services of a CMResource class 1004. 

25 CMResource handles the general resources of 

character encoding, ninneric formatting and date 
formatting. Figure 18 illustrates a CMResource class 
diagram 1030. The string and message specific 
resources are handled by the COAppResource classes. The 

30 CMResource 1032 is the composite resource object that 

delegates calls to contained COAppResource objects. 
A hash table of COAppResource ' s is populated in 
CMResource as requests are received. The table 
includes a COAppResource bundle for each of the main 

35 functional areas within the Webstation application, 
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i.e. App, GDD, Rules, NEMS, Reporting, Security, 
Provisioning, etc. The "App" bundle includes the 
global resources. 

A resource bundle is typically loaded when a 
request is received. The static method 
COAppResource.getAppResource loads the bundle for a 
specific locale. CMResource provides the methods 
getStringResource and getMessageResource for delegating 
to the COAppResource bundle to retrieve the translated 
string or message. If a locale has not been set, the 
locale defaults to United States. 

The COAppResource class generally handles 
retrieving static strings and/ or constructing messages. 
The static method getAppResource { ) returns an 
application specific internationalization resource and 
is used by CMResource to instantiate the resource 
bundles for each functional area. The methods 
getStringResource and getMessageResource delegate to 
the resource specific CMXXXStrings or CMXXXPhrases for 
string or message lookup. 

Figure 19 illustrates an example of a 
CMXXXString class diagram 1040. A 

ConcreteResourceBundle 1042 is an abstract class to be 
used for defining string and message resources. The 
key-value pairs are defined in a data structure which 
is returned in a method getContents ( ) . This sxibclass 
is typically named using the format: 

AppResource + "Strings" + + language + 
+ country , where the AppResource is the name of the 
application resource, language is the language being 
translated, and the country uses predefined tags for 
country labels, e.g., US = United States. 

An AppResource typically exists for each 
functional area within the webstation. In addition, 
there is a global list of resources that are common to 
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many of the functional areas. For example, strings 
such as "OK", "Cancel" which are used throughout the 
GUI, are typically placed in the global list- The class 
naming convention is "CMXXXStrings" 1044, where "XXX" 
represents the functional area, such as rules, GDD, 
NEMS and so on. In the case of the global string 
resources, this class is named CMAppStrings , in 
reference to the main class webstation.cmco.CMApp 

Because translation of phrases generally may 
require more than one-to-one mappings of words, a 
different methodology is used. Figure 20 illustrates 
an example of a CMXXXPhrases class diagram 1052. A 
phrase template includes variables for inserting data 
into a location that is applicable for that particular 
language. The CMXXXPhrases class 1054 description is 
otherwise identical to the CMXXXStrings 1044 given 
above. 

While the invention has been particularly 
shown and described with respect to preferred 
embodiments thereof, it will be understood by those 
skilled in the art that* the foregoing and other changes 
in form and details may be made therein without 
departing from the spirit and scope of the invention. 
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CIiAIMS 



What is claimed is: 



1 1. A web -based call manager webs tat ion 

2 system for controlling and monitoring customer's 

3 telecommunication network routing configurations via an 

4 integrated interface, the system comprising: 

5 a client browser application located at a 

6 client workstation for enabling interactive web-based 

7 communications with the call manager webstation system 

8 and providing the integrated interface; 

9 at least one secure server for managing one 

10 or more customer session (s) over the Internet, the 

11 secure server supporting a secure socket connection 

12 enabling encrypted communications between the client 

13 browser application and the secure server; 

14 . configuring device launched via the client 

15 browser, for enabling a customer to monitor, define, 

16 and manipulate call routing parameters, the configuring 

17 device further formatting customer defined parameters 

18 into client message transactions and communicating the 

19 client message transactions to the secure server over 

20 the secure socket connection; 

21 a routing engine for maintaining call routing 

22 rules and interfacing with a plurality of network 

23 control elements for directing call routing and 

24 receiving data statistics, the routing engine further 
25. using the rules, the data statistics, and the customer 

26 defined parameters in determining where to route calls, 

27 wherein the customer is enabled to control 

28 call routing via the web-based integrated interface. 
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1 2* The web-based call manager webstation 

2 system as claimed in claim 1, wherein the system 

3 further includes a proxy server for processing a 

4 plurality of transaction requests received from the 

5 configuring device via the secure server by opening a 

6 connection to the routing engine and retrieving 

7 information relating to the transaction requests and 

8 forwarding back the infomation to the configuring 

9 device via the secure server, and wherein the 

10 configuring device presents the information to the 

11 customer at the client workstation. 

1 3. The web-based call manager webstation 

2 system as claimed in claim 2, wherein the system 

3 further includes one or more database (s) for storing 

4 the data statistics generated by the routing engine and 

5 the plurality of network control elements, said one or 

6 more databases residing with the proxy server, the 

7 proxy server further processing predetermined 

8 transaction requests locally by retrieving information 

9 related to the transaction requests from said one or 

10 more database (s), and forwarding the information to the 

11 configuring device. 

1 4. The web-based call manager webstation 

2 system as claimed in claim 1, wherein the secure server 

3 further includes: 

4 a session manager for maintaining session 

5 information associated with the customer session, 

6 . the session information including a session 

7 timestcunp representing a time of receipt of a previous 

8 communication transaction associated with the customer 

9 session, 
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1 wherein the session manager updates the 

2 session timestamp with a current time when the secure 

3 server receives a current communication transaction 

4 from the configuring device. 

1 5- The web-based call manager webstation 

2 system as claimed in claim 4, wherein the secure server 

3 further includes a device for monitoring the session 

4 timestamp, and wherein if a time difference between a 

5 current monitoring time and the session timestamp 

6 exceeds a predefined value, the device for monitoring 

7 clears the session information associated with the 

8 customer session, whereby the customer session is no 

9 longer deemed valid. 

1 6* The web-based call manager webstation 

2 system as claimed in claim 1, wherein the system 

3 further enables the customer to view, define, and 

4 manipulate call routing parameters which are applied on 

5 a call by call basis. 

1 7, The system as claimed in claim 1, wherein 

2 the system further enables the customer to write call 

3 routing rules via the configuring device, and the 

4 . configuring device further communicates the rules to 

5 the routing engine for use during the call routing. 

1 8, The web-based call manager webstation 

2 system as claimed in claim 7, wherein the call routing 

3 rules are applied on a call by call basis. 

1 9. The web-based call manager webstation 

2 system as claimed in claim 7, wherein the system 
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1 further enables the customer to test a rules set 

2 comprising the rules written by the customer by 

3 simulating call scenarios in which to test a rules set 

4 logic. 

1 10. The web-based call manager webstation 

2 system as claimed in claim 9, wherein the configuring 

3 device further enables the customer to define call 

4 context parameters for simulating the call scenarios, 

5 wherein the customer is enabled to control the 

6 simulated call scenarios in which to test the rules 

7 set. 

1 11. The web-based call manager webstation 

2 system as claimed in claim 10, wherein the call context 

3 parameters include called- number, ANI, CED, carrier, 

4 data and time of a simulated call. 

1 12. The web-based call manager webstation 

2 system as claimed in claim 10, wherein the call context 

3 parameters which may be defined by the customer further 

4 include call destinations affecting load balancing. 

1 13. The web-based call manager webstation 

2 system as claimed in claim 10, wherein the call context 

3 ■ parameters which may be defined by the customer further 

4 include quotas affecting load balancing. 

1 14. The web-based call manager webstation 

2 system as claimed in claim 9, wherein the system 

3 further enables the customer to step through the 

4 simulation one line at a time. 
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1 15. The web-based call manager webstation 

2 system as claimed in claim 9, wherein the system 

3 further enables the customer to run through an entire 

4 call simulation without stopping when testing the rules 

5 set. 

1 16. The web-based call manager webstation 

2 system as claimed in claim 9, wherein the configuring 

3 device further enables the customer to select to view 

4 status information associated with a call being 

5 simulated during the simulation. 

1 17. The web-based call manager webstation 

2 system as claimed in claim 16, wherein the status 

3 information view includes a destination status view. 

1 18. The web -based call manager webstation 

2 system as claimed in claim 16, wherein the status 

3 information view includes a destination details view. 

1 19. The web-based call manager webstation 

2 system as claimed in claim 16, wherein the status 

3 information view includes a call detail records view. 

1 20. The web -based call manager webstation 

2 system as claimed in claim 1, wherein the call routing 

3 . parameters which may be viewed via the configuring 

4 device include agent pool statistics, and wherein the 

5 customer is enabled to perform load-balancing based on 

6 the agent pool statistics. 

1 21. The web -based call manager webstation 

2 system as claimed in claim 20, wherein the agent pool 
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1 ' Statistics include average call handling time. 

1 22. The web-based call manager webstation 

2 system as claimed in claim 20, wherein the agent pool 

3 statistics include a number of agents. 

1 23. The web-based call manager webstation 

2 system as claimed in claim 20, wherein the agent pool 

3 statistics include a number of calls routed to each 

4 destination. 

1 24. The web-based call manager webstation 

2 system as claimed in claim 1, wherein the call routing 

3 parameters which may be viewed and modified include 

4 agent pool capacity tables, wherein the customer is 

5 enabled to provide default staffing allocation for use 

6 by a load balancing algorithm performing load 

7 balancing. 

1 25. The web-based call manager webstation 

2 system as claimed in claim 1, wherein the call routing 

3 parameters which may be viewed and modified include 

4 termination destination identifiers. 

1 26. The web-based call manager webstation 

2 system as claimed in claim 25, wherein the termination 

3 destination identifiers include a single call 

4 termination into a single telephone instrument. 

1 27. The web-based call manager webstation 

2 system as claimed in claim 25, wherein the termination 

3 destination identifiers include a line termination into 

4 a private branch exchange (PBX) . 
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1 28. The web-based call manager webstation 

2 system as claimed in claim 25, wherein the termination 

3 destination identifiers include a single call 

4 termination into an ACD. 

1' 29. The web-based call manager webstation 

2 system as claimed in claim 25, wherein the termination 

3 destination identifiers include a group of destination 

4 identifiers terminating into an ACD. 

1 30. The web-based call manager webstation 

2 system as claimed in claim 1, wherein the call routing 

3 parameters which may be monitored and modified include 

4 distribution protocols for selecting destination 

5 identifiers for routing calls. 

1- 31. The web-based call manager webstation 

2 system as claimed in claim 30, wherein the distribution 

3 protocols include a round- robin protocol. 

1 32. The web-based call manager webstation 

2 system as claimed in claim 30, wherein the distribution 

3 protocols include a direct protocol in which routing 

4 calls are based on a percentage allotted to each 

5 destination identifier. 

1 33. The web-based call manager webstation 

2. system as claimed in claim 1, wherein the call routing 

3 parameters which may be viewed and modified include 

4 rule routing. quotas associated with destinations. 

1 34. The web-based call manager webstation 
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1 system as claimed in claim 1, wherein the call routing 

2 parameters which may be monitored and modified include 

3 value lists which are used to determine one or more 

4 characteristic (s) of an incoming call, wherein rules 

5 are executed based on the one or more 

6 characteristic (s) . 

1. 35. The web-based call manager webstation 

2 system as claimed in claim 1, wherein the call routing 

3 parameters which may be monitored and modified include 

4 parameters affecting authentication and entitlements to 

5 the system. 

1 36. The web-based call manager webstation 

2 system as claimed in claim 35, wherein the parameters 

3 affecting authentication and entitlements include 

4 business hierarchies representing corporations and 

5 account groups. 

1 37. The web-based call manager webstation 

2 system as claimed in claim 35, wherein the parameters 

3 affecting authentication and entitlements include user 

4 identifiers. 

1' 38. The web-based call manager webstation 

2 system as claimed in claim 35, wherein the parameters 

3 affecting authentication and entitlements include data 

4 access privileges. 

1 39. The web-based call, manager webstation 

2 system as claimed in claim 2, wherein the system 

3 further enables the customer to view near real-time 

4 displays of peg counts based on routing rules, the 
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1 plurality of transaction requests including a request 

2 to monitor the peg counts, and the information includes 

3 current peg counts retrieved and forwarded to the 

4 customer by the customer via the configuring device. 

1 40. The web-based call manager webstation 

2 system as claimed in claim 39, wherein the information 

3 including current peg counts are continuously retrieved 

4 and forwarded to the configuring device, the 

5 configuring device further updating the information 

6 continuously as the information is received. 

1 41. The web- based call manager webstation 

2 system as claimed in claim 2, wherein the system 

3 further enables the customer to view near real-time 

4 displays of call center ACD statistics, the plurality 

5 of transaction requests including a request to monitor 

6 the call center ACD statistics, and the information 

7 includes current call center ACD statistics retrieved 

8 and foirwarded to the customer via the configuring 

9 device . 

1 42. The web-based call manager webstation 

2 system as claimed in claim 41, wherein the information 

3 including current call center ACD statistics are 

4 continuously retrieved and forwarded to the configuring 

5 device, the configuring device further updating the 

6 information continuously as the information is 

7 received. 

1 43. The web-based call manager webstation 

2 system as claimed in claim 1, wherein the configuring 

3 device further enables the customer to run provisioning 
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reports , 



1 44. The web-based call manager webstation 

2 system as claimed in claim 1, wherein the configuring 

3 " device further enables the customer to run statistical 

4 reports. 

1 45. The web-based call manager webstation 

2 system as claimed in claim 1, wherein the configuring 

3 device further enables the customer to extract data 

4 from the routing engine and the plurality of network 

5 control elements for presentation to the customer. 

1 46. The web-based call manager webstation 

2 system as claimed in claim 1, wherein the system 

3 ' further enables the customer to display status of the 

4 web -based call manager webstation system via the 

5 configuring device. 

1 47. The web-based call manager webstation 

2 system as claimed in claim 1, wherein the system 

3 further presents alarms related to running of the web- 

4 based call manager webstation system via the 

5 configuring device. 

1 48. The web-based call manager webstation 

2* system as claimed in claim 1, wherein the system 

3 further enables the customer via the configuring device 

4 to administer host systems including the routing 

5 engine . 

1 49. The web-based call manager webstation 

2 system as claimed in claim 1, wherein the system 
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1 further enables the customer via the configuring device 

2 to administer host systems including gateway systems 

3 connecting the routing engine to the plurality of 

4 network control elements, 

1- 50. The web-based call manager webstation 

2 system as claimed in claim 1, wherein the configuring 

3 device further includes a branding device for branding 

4 presentation views in a specific context, 

1 51. The web-based call manager webstation 

2 system as claimed in claim 1, wherein the configuring 

3 device further includes a translation device for 

4 supporting multiple languages, wherein texts are 

5 displayed by the configuring device in a language of a 

6 geographic locale. 

1 52. The web-based call manager webstation 

2 system as claimed in claim 20, wherein the agent pool 

3 statistics include one selected from a group consisting 

4 of: 

5 a number of calls abandoned during a 

6 reporting interval; 

7 a number of calls answered during a reporting 

8 interval ; 

9 a number of calls completed during a 

10 reporting interval; 

11 a number of agents currently handling active 

12 calls; 

13 a number of agents currently performing 

14 after- call activities; 

15 a number of agents logged in to the ACD but 

16 who are not currently available to handle calls due to 
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1 an auxiliary work; 

2 a number of agents available including those 

3 currently handling active calls; 

4 a number of agents currently logged in to the 

5 ACD including those agents in auxiliary work state; 

6 a number of calls currently in queue waiting 

7 for an available agent; 

8 a percentage of calls abandoned during a 

9 reporting interval; 

10 a number of seconds the oldest call in queue 

11 has been waiting; 

12 an average time to handle a call including 

13 talk time and after -call work time; 

14 an average time the calls wait in queue for 

15 the available agents; 

16 an average time in queue for the calls which 

17 were abandoned; and 

18 * a ratio of a n\imber of calls to a number of 

19 agents working on calls. 

1 53. The web-based call manager webstation 

2 system as claimed in claim 52, wherein the agent pool 

3 statistics includes any combination of the group 

4 thereof . 

1 54. A method for controlling customer's call 

2 routing configurations via a web -based integrated 

3 interface at a customer workstation having a client 

4 ■ browser application for enabling interactive web-based 

5 communications between the customer and the integrated 

6 interface, the method comprising: 

7 managing a client session over the Internet 

8 by providing a secure server which supports a secure 
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1 socket connection to enable encrypted communications 

2 between the client browser application and the secure 

3 server; 

4 maintaining call routing rules for use in 

5 directing call routing via one or more network control 

6 elements; 

7 collecting data statistics from the network 

8 " control elements; 

9 communicating customer -defined call routing 

10 parameters associated with the call routing rules, 

11 wherein the call routing rules, the data 

12 statistics, and the customer defined call routing 

13 parameters are used by the network control elements to 

14 determine where to route calls, and the customer is 

15 enabled at the customer workstation to control call 

16 routing of individual calls. 

1 55. The method according to claim 54, 

2 wherein the method further comprises: 

3 downloading the data statistics to the 

4 customer workstation via the secure server; and 

5 presenting the data statistics to the 

6 customer; 

7 wherein the customer is enabled to monitor 

8 status of the network control elements at the customer 

9 workstation. 

1 56. The method according to claim 55, 

2 wherein the data statistics include call center ACD 

3 . statistics, and the customer is enabled to monitor a 

4 status of one or more call center (s) . 
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1 57. The method according to claim 56, 

2 wherein the method of presenting the data statistics 

3 further includes continuously updating the data 

4 statistics with current data at the customer 

5 workstation, and the customer is enabled to monitor the 

6 status of the one or more call center (s) in near real 

7 time. 

1 58. The method according to claim 55, 

2 wherein the method of presenting further includes 

3 displaying the data statistics in a graphical format. 

1 59. The method according to claim 54, 

2 wherein the method further includes: 

3 enabling the customer to write call routing 

4 rules; and 

5 communicating the call routing rules via the 

6 secure server; 

7 using the call routing rules for the call 

8 routing of individual calls. 

1 60. The method according to claim 59, 

2 wherein the method further includes: 

3 simulating call scenarios; and 

4 running the call routing rules in the 

5 simulated call scenarios for testing, 

6 wherein the customer is enabled to test the 

7 call routing rules ♦ 

1 61. The method according to claim 60, 

2 wherein the step of simulating further includes: 

3 accepting from the customer workstation, 

4 customer -defined call context parameters which are used 
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1 to simulate the call scenarios; 

2 communicating the customer -defined call 

3 context parameters via the secure server; and 

4 using the customer- defined call context 

5 parameters in simulating the call scenarios, 

6 wherein, the customer is enabled to control a 

7 simulation of the call scenarios in which to test the 

8 call routing rules. 

1 62, The method according to claim 60, 

2 wherein the step of running the call routing rules 

3 further includes: 

4 stopping after each line, wherein the 

5 customer is enabled to debug the call routing rules 

6 line by line. 

1 63. The method according to claim 62, 

2 wherein the step of running the call routing rules 

3 further includes: 

4 presenting data statistics from the network 
5- control elements after the step of stopping, 

6 wherein the customer is enabled to monitor 

7 status information during the testing. 

1 64. The method according to claim 54, 

2 wherein the step of managing a client session further 

3 includes : 

4 maintaining session information associated 

5 with the client session; 

6 including a timestamp in the session 

7 information for representing a time of receiving of a 

8 previous communication transaction associated with the 

9 client session; 
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1 receiving a current communication transaction 

2 from the customer workstation; 

3 updating the timestamp with a time of receipt 

4 of the current communication transaction. 

1 65. The method according to claim 64, 

2 wherein the step of managing a client session further 

3 comprises: 

4 monitoring the timestamp; 

5 comparing current monitoring time with the 

6 timestamp; and 

7 clearing the session information having the 

8 timestamp, if a time difference between the current 

9 monitoring time and the timestamp exceeds a predefined 
10 value. 

1- 66. The method according to claim 54, 

2 wherein the method further includes: 

3 translating texts presented to the customer 

4 into a language used in a geographic locale where the 

5 customer workstation is located. 

1 67. The method according to claim 54, 

2 wherein the method further includes: 

3 branding presentation views communicated to 

4 the customer at the customer workstation to denote 

5 customer- specific context. 

1 68 » A web-based call manager webstation 

2 system for controlling and monitoring customer's 

3 telecommunication network routing configurations, the 

4 system comprising: 

5 a client browser application located at a 

6 - client workstation for enabling interactive web -based 
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1 ' communications with the call manager webstation system; 

2 at least one secure server for managing one 

3 or more customer session (s) over the Internet, the 

4 secure server supporting a secure socket connection 

5 enabling encrypted communications between the client 

6 browser application and the secure server; 

7 configuring device launched via the client 

8 browser, for enabling a customer to monitor, define, 

9 and manipulate call routing parameters, the configuring 

10 device further formatting customer defined parameters 

11 into client message transactions and communicating the 

12 client message transactions to the secure server over 

13 the secure socket connection; 

14 a routing engine for maintaining call routing 

15 rules and interfacing with a plurality of network 

16 control elements for directing call routing and 

17 receiving data statistics, the routing engine further 

18 using the rules, the data statistics, and the customer 

19 detfined parameters in determining where to route calls, 

20 wherein the customer is enabled to control 

21 call routing via the client browser application, 

1- 69* The web-based call manager webstation 

2 system as claimed in claim 68, wherein the configuring 

3 device further includes a branding device for branding 

4 presentation views according to specific customer 

5 context . 

l' 70. The web-based call manager webstation 

2 system as claimed in claim 68, wherein the configuring 

3 device further includes a translation device for 

4 supporting multiple languages, wherein texts are 

5 displayed by the configuring device in a language of 
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1 . geographic locale. 

1 71. The web-based call manager webstation 

2 system as claimed in claim 68, wherein the configuring 

3 device further includes a translation device for 

4 supporting multiple languages, wherein texts are 

5 . displayed by the configuring device in a language 

6 selected by the customer. 

1 72. The web-based call manager webstation 

2 system as claimed in claim 68, wherein the configuring 

3 device further enables the customer to contact service 

4 personnel at the enterprise for seeking services 

5 related to the controlling and monitoring of the 

6 customer's telecommunication network routing. 
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